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OPEN  ARCHITECTURE  FOR  ELECTRONIC 
DESIGN  AND  SUPPORT  TOOLS 


Abstract 

Under  Phase  1  SBIR  funding  we  have  outlined  an  Open  Architecture  for  Testability  and 
Maintainability  related  tools.  We  have  developed  a  strawman  neutral  format  for  dependency 
models  -  the  most  important  and  most  difficult  component  of  the  proposed  open  architecture, 
and  we  have  formalized  that  model  using  EXPRESS.  We  have  shown  in  detail  how  our 
proposed  standards  fit  synergistically  into  the  framework  being  developed  by  the  IEEE  SCC20 
committee,  and  we  have  received  their  provisional  approval  to  proceed  under  the  formal 
sponsorship  of  SCC20  (which  is  an  ANSI  approved  standards  developer).  Most  importantly, 
we  have  coordinated  with  a  large  group  of  vendors  and  users  of  testability  and  maintainability 
related  tools,  both  inside  and  outside  of  DOD,  and  have  proven  that  there  is  considerable 
support  for  such  standards. 

These  accomplishments  exceed  our  original  goals  for  the  Phase  1  effort,  and  demonstrate  that 
with  Phase  2  support,  we  will  certainly  succeed  in  securing  an  ANSI  standard  that  vendors  will 
support.  The  standard  will,  in  fact,  create  an  entirely  new  domain  of  products  which  will 
generate  and/or  use  data  compliant  with  the  Open  Architecture  specification.  Without  the  Open 
Architecture  specification,  there  would  be  insufficient  potential  customers  to  justify  the 
development  of  these  new  products.  As  part  of  the  Phase  1  effort,  we  have  implemented  a 
prototype  of  one  such  tool,  which  we  will  develop  to  completion  under  Phase  2  funding. 


1.  Introduction 

The  Open  System  Interconnection  Reference  Model  provided  a  means  by  which  a  wide  variety 
of  communication  equipment  could  be  made  to  easily  interoperate.  It  provided  a  means  by 
which  communication  and  network  problems  could  be  viewed  at  a  particular  level  with  no 
concern  for  how  lower  levels  would  implement  their  capabilities,  and  with  no  concern  for  the 
details  of  higher  levels.  The  Open  System  Interconnection  Reference  Model  has  had  a 
tremendous  impact  on  the  ease  with  which  diverse  equipment  can  be  made  to  interoperate. 

This  proposal  defines  the  structure  of  the  equivalent  of  an  OSI  model  for  system  design  aids, 
reliability  and  testability  evaluation  aids,  automatic  test  vector  generation  equipment,  built  in 
test  design  aids,  diagnostic  expert  systems,  and  other  similar  equipment.  The  basic  concept 
presented  defines  the  same  type  of  layered  interface  standards  as  comprise  the  OSI  model 
except  that  the  interfaces  relate  to  the  diagnosability,  testability,  and  reliability  of  systems.  If 
fully  successful,  our  Open  System  Architecture  will  allow  design  and  diagnosis  tools  to 
interoperate  as  easily  as  diverse  equipment  can  communicate  via  the  OSI  model.  The 
architecture  we  propose  imposes  no  constraint  on  how  the  internals  of  tools  are  implemented. 
The  architecture  is  a  set  of  standard  neutral  formats  for  representing  the  key  data  structures 
required  for  automation  of  testability  analysis,  diagnosability  analysis,  coverage  analysis, 
automated  diagnosis,  etc.  Tools  which  can  input  and/or  output  data  in  these  formats  can 
interoperate. 

Computer  systems,  other  electronic  systems,  and  even  mechanical  systems  are  becoming 
increasingly  complex.  Because  of  this  increasing  complexity,  it  has  become  essential  to 
develop  automated  tools  to  assist  a  designer.  There  are  many  commercial  products  which 
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provide  aids  for  the  design  and  validation  problem.  There  are  systems  which  help  establish  the 
reliability  and  testability  of  a  current  design.  There  are  products  which  help  generate  self 
testing  approaches  for  systems,  and  there  are  a  wide  range  of  automatic  test  equipment  None 
of  these  products  interoperate  in  an  integrated  manner.  One  set  of  commercial  tools 
cannot  be  easily  used  to  confirm  the  results  of  another  because  they  use  different 
representations  of  the  design,  different  definitions  of  values,  and  different  output  formats. 
There  is  a  natural  hierarchy  of  evaluation  of  reliability,  testability,  and  diagnosabihty  and  there 
are  different  tools  that  operate  at  different  levels  of  that  hierarchy,  but  current  tools  cannot  pass 
the  results  of  one  level  of  evaluation  to  the  next  level  of  analysis.  Our  work  addresses  this 
critical  issue  -  the  interoperability  of  existing  and  future  design  and  maintenance  tools.  Our 
work  to  date  has  proven  that  our  concept  is  technically  feasibility,  and  that  both  users  and 
vendors  support  the  idea. 

In  addition  to  commercial  products,  there  is  a  vast  amount  of  current  DOD  supported  research 
aimed  at  addressing  the  above  problems.  Most  ongoing  programs  are  stand-alone  tools  which 
help  with  specific  aspects  of  military  system  design  and  life  cycle  support  problems.  These 
tools  do  not  interoperate. 

There  is  some  recognition  of  the  need  for  an  Open  Architecture  for  tools  related  to  the  testing 
and  maintenance  of  systems,  and  some  of  the  work  of  Standards  Coordinating  Committee  20 
within  the  IEEE  relates  to  this  problem.  At  his  time,  however,  their  work  has  been  limited  to 
the  low  level  aspects  of  testing.  The  work  which  we  have  done  under  this  task  fits  perfectly 
within  the  overall  goals  of  SCC20,  and  they  have  agreed  that  our  work  will  be  done  under  the 
AI-ESTATE  Committee  of  SCC20.  It  is  through  this  committee  that  our  work  will  become  an 
ANSI  standard. 

During  this  Phase  1  SBIR  project  we  have  accomplished  the  following: 

a.  We  have  refined  the  concept  of  an  Open  Architecture  for  testability  analysis  tools, 
maintenance  aids,  logistics  support  prediction  tools,  and  automated  training  related  tools,  and 
have  identified  three  areas  where  a  standard  could  be  achieved  quickly.  The  three  proposed 
standards  are  a  dependency  model,  ambiguity  group  model,  and  a  fault  tree  model. 

b.  We  have  studied  the  cun-ent  work  items  of  ongoing  ANSI  approved  committees, 
and  identified  the  SCC20  as  the  best  formal  sponsor  for  our  work.  What  we  propose  fits 
perfectly  into  their  long  range  goals. 

c.  We  have  prepared  and  presented  a  briefing  to  the  SCC20,  and  secured  their  interim 
approval  to  proceed. 

d.  We  have  studied  and  in  some  cases  obtained  copies  of  current  commercial  tools 
which  are  used  for  testability  analysis,  and  for  diagnostic  aids. 

e.  We  have  developed  a  strawman  formal  data  model  for  dependency  model  data,  and 
have  tentatively  selected  ISO  CD  10303-21  as  the  data  encoding  standard.  Formal  data  models 
for  ambiguity  groups  and  fault  trees  should  be  less  difficult  to  develop. 

f.  We  have  generated  one  relatively  complex  example  dependency  model  and  verified 
that  the  dependency  data  would  be  representable  within  our  strawman  formal  data  model. 

g.  We  have  met  with  numerous  companies  which  produce  testability  analysis  tools, 
and  which  produce  real-time  diagnosis  aids  and  have  secured  strong  promises  of  support.  We 
have  also  met  with  key  leaders  of  current  ANSI  Committees  and  secured  their  promise  of 
support. 
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h.  We  have  designed  and  coded  a  hypermedia  system  which  shows  what  a  dependency 
model-based  tool  could  be  like.  For  our  system  to  be  widely  used,  dependency  models  of 
systems  would  need  to  be  available  in  a  standard  format. 

i.  We  have  developed  an  example  Hypermedia  automated  Test  Requirements 
Document.  The  input  to  this  tool  consists  of  ambiguity  group  data,  and  fault  tree  data,  plus 
other  ancillary  data. 

j.  We  have  demonstrated  how  the  above  Hypermedia  systems  can  be  linked  to 
paperless  Hypermedia  service  manuals.  This  is  usable  as  a  performance  aid  for  technicians, 
and  also  could  serve  as  the  kernel  of  a  system  for  automated  computer-based  training.  We 
have  the  capability  to  input  existing  service  manuals  (available  in  paper  form  only)  into  the 
Hypermedia  environment  using  document  scanning  technology.  We  can  also  input  manuals 
available  in  computer  readable  form. 


2.  Need  for  Standard  DOD  Data  Interchange  Formats  Related  to  Testability 
and  Maintainability 

Table  1  lists  a  number  of  ongoing  DOD  programs  which  are  developing  tool  for  improving  the 
testability  and  maintainability  of  weapons  systems.  The  MATE  Program  does  concern  itself 
with  standards  but  only  at  the  level  of  the  test  equipment  itself.  MATE  is  not  relevant  to  the 
higher  level  issues  of  concern  in  Concurrent  Engineering.  ABET,  the  last  entry  in  Table  1, 
will  be  discussed  in  more  detail  in  section  4.  None  of  the  other  programs  shown  interoperate 
at  all.  Each  is  a  stand-alone  effort. 

Table  2  lists  numerous  DOD  programs  which  are  developing  performance  aids  to  help 
technicians  during  the  diagnosis  and  repair  process.  As  in  the  case  of  the  programs  listed  in 
table  1,  none  of  the  resulting  tools  will  interoperate  in  any  way.  There  is  a  need  for  a  standard 
neutral  format  for  representing  the  Unit  T  tnder  Test  so  that  the  same  input  can  be  used  for  all  of 
the  tools  which  require  the  same  fundamental  information  about  the  Unit  Under  Test. 

DOD  tools  related  to  testability  and  maintainability  all  use  ad-hoc  individual  formats  for  their 
input  and  output  hence  one  tool  cannot  be  used  to  validate  or  refine  the  results  of  another. 

According  to  the  institute  For  Defense  Analysis  Report  P-2300  dated  January  1990,  some  of 
the  most  significant  problems  within  DOD  related  to  testability  and  maintainability  analysis  are 
listed  below.  The  quoted  sentences  are  directly  from  the  IDA  report. 

"DOD  maintenance  data  collection  often  originates  from  verbal  inputs  with  no  rigid 
format  requirements."  Because  of  this,  it  is  difficult  to  make  changes  to  improve  the 
system  based  on  assessments  of  the  current  problem  areas.  The  entire  system  runs 
"open  loop." 

"DOD  has  antiquated,  error  prone  maintenance  data  collection  and  feedback 
capabilities."  Without  formal  standards  for  the  data,  accurate  results  which  can  be 
automatically  fed  into  test  systems  to  improve  test  and  repair  procedures  is  not  possible. 

"DOD  lacks  centralized  data  analysis  centers  focusing  on  diagnostic  accuracy."  The 
concept  of  a  centralized  data  analysis  center  would  be  difficult  to  implement  with  data 
not  provided  in  a  consistent  format  with  consistent  meaning. 
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"DOD  maintenance  and  support  functions  are  paper  intensive."  Paper  manuals  are 
required  because  there  are  not  adequate  "computer-based"  manuals. 

As  described  in  the  IDA  report,  there  is  almost  complete  lack  of  feedback  from  the  field  which 
could  be  used  to  enhance  a  system's  design,  production,  diagnosis  and  repair  strategies, 
logistics  support,  and  technician  training.  The  data  items  shown  at  the  top  of  figure  1  are  all 
components  within  the  strawman  formal  data  model  to  be  presented  later.  If  our  program 
proceeds,  and  we  are  successful  in  refining  and  adopting  the  proposed  standard,  then  all  of 
these  data  items  will  be  available  in  a  standard  format  with  a  standard  formal  meaning.  Not 
only  will  data  collection  now  be  meaningful  but  more  importantly,  that  data  can  be  fed  back 
automatically  into  the  Dependency  Model  to  immediately  optimize  the  test  and 
repair  procedures  based  on  the  field  data.  If  automated  training  systems  are  based  on 
the  standard  models,  then  the  training  system  will  also  be  automatically  updated.  This  point 
will  be  elaborated  more  later  in  this  report  after  more  background  has  been  provided  on  the 
model  itself  and  on  the  types  of  tools  which  will  likely  use  the  model. 

For  Concurrent  Engineering  to  be  effective,  design  data  must  be  sharable  and  usable  by  design 
engineers,  by  test  and  maintenance  system  developers,  by  the  logistics  support  community,  by 
production  personnel,  and  by  training  and  manpower  related  personnel.  This  is  shown 
graphically  in  figure  2.  The  strawman  formal  data  model  for  dependency  models,  for 
ambiguity  group  data,  and  for  fault  trees  contains  ancillary  data  which  includes  the  data  items 
shown  on  figure  2,  plus  much  more  data.  More  work  will  certainly  be  required  to  expand  the 
current  strawman  model,  but  we  have  made  an  aggressive  start  in  formalizing  and 
standardizing  testability  and  maintainability  related  data. 


3.  Layered  Architectures 

The  development  of  standards  appears  to  be  most  effective  when  individual  standards 
aggregate  together  into  an  overall  superstructure  which  relates  each  individual  standard  to  the 
intent  of  the  entire  system.  Layered  architectures  have  been  very  effective  in  providing  that 
superstructure  and  there  are  several  examples  of  a  family  of  standards  which  fit  within  a 
layered,  hierarchical  architecture. 

The  best  example  of  a  layered  architecture  is  the  International  Standards  Organization  (ISO) 
Open  System  Interconnection  (OSI)  architecture.  OSI  is  composed  of  seven  layers,  each  of 
which  defines  specific  services  and  protocols  provided  at  that  level.  Figure  3  shews  the  OSI 
model.  The  layers  are  described  below.  The  key  concept  is  that  the  functions  at  one  level  do 
not  need  to  know  the  details  of  the  processes  at  lower  levels  or  at  higher  levels. 


Layer  1 

Layer  2 
Layer  3 

Layer  4 
Layer  5 

Layer  6 


Physical  Layer 

Data  Link  Layer 
Network  Layer 

Transport  Layer 
Session  Layer 

Presentation  Layer 


Provides  direct  mechanical  and  electrical  connection  between 
computer  systems  or  network  nodes. 

Controls  and  checks  the  direct  physical  connection 

Provides  the  logical  end-to-end  connection  between  control 
systems  when  there  are  intermediaries 

Controls  and  checks  the  logical  end-to-end  connection 

Provides  the  logical  connection  between  control  programs,  or 
between  programs  and  services 

Defines  data  representations  and  required  data  conversion 
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Layer  7  -  Application  Layer  Provides  data  services  and  data  management,  and  may  include 

actual  use  of  the  data 


Other  examples  of  layered  architectures  are  the  National  Institute  of  Standards  and  Technology 
Standard  Robot  Control  System  Architecture,  and  the  related  National  Aeronautics  and  Space 
Administration  NASREM  architecture.  In  these  architectures,  the  tasks  of  providing  intelligent 
control  to  a  robot  is  layered,  with  the  lowest  layers  providing  high  speed  commands  for  the 
robot  to  perform  primitive  tasks,  and  at  the  highest  levels,  control  is  long  term,  and  provides 
task  level  direction  such  as  move  to  an  object  at  an  initial  location,  grasp  that  object,  and  then 
move  to  a  destination  location  and  release  die  object. 

We  have  defined  a  layered  architecture  for  testability  and  maintainability  analysis.  Layered 
architectures  have  been  successful  in  other  applications,  and  we  believe  they  are  a  good  match 
with  the  technical  requirements  related  to  system  testability  and  maintainability  analysis.  The 
concept  of  a  layered  architecture  also  matches  well  with  the  work  of  SCC20  described  in  the 
following  section. 


4.  IEEE  Standards  Coordinating  Committee  20 

Figure  4  summarizes  the  work  of  the  IEEE  Standards  Coordinating  Committee  (SCC)20.  The 

basic  concept  is  a  layered  architecture. 

4.1  SCC20  Reference  Model  Instrument  Layer 

The  lowest  layer  is  the  instrument  layer,  and  specific  work  is  ongoing  (IEEEP981)  to 
develop  a  Test  Resource  Description  Language.  This  language  would  be  used  to  define 
the  specific  details  of  the  test  equipment  available.  It  would  define  the  signals  to  control 
the  specific  test  instruments,  and  would  also  define  the  signals  need  to  control  the 
electronic  switching  matrix  used  to  dynamically  connect  test  equipment  to  the  required 
test  points.  The  output  from  the  next  higher  level,  plus  the  RDL  description  of  the  test 
equipment  details  would  be  used  to  generate  the  proper  signals  to  the  test  equipment  so 
that  the  test  programs  will  execute  properly. 

4.2  SCC20  Reference  Model  ATE  System  Layer 

The  next  layer  is  the  ATE  System  Layer.  Everything  above  this  layer  defines  tests  in 
terms  of  virtual  test  equipment,  independent  of  what  test  equipment  with  what 
capabilities  are  actually  available.  The  Test  Equipment  Description  Language  (IEEE 
P993)  will  be  used  to  specify  what  test  equipment  is  actually  present  and  what  are  its 
capabilities.  (TEDL  does  not  specify  how  to  actually  control  the  test  equipment  -  that  is 
done  by  RDL). 

4.3  SCC20  Reference  Model  Test  Procedure  Layer 

The  Test  Procedure  Layer  gives  the  actual  test  program.  A  major  part  of  the  work  of 
the  SCC20  is  focused  on  a  project  called  "Ada  Based  Environment  for  Test"  (ABET) 
(IEEE  1226)  and  much  of  the  current  work  of  the  ABET  Committee  deals  with  the  Test 
Procedure  Layer.  Today,  test  procedures  are  typically  specified  in  ATLAS  (IEEE  716), 
and  ABET  will  be  the  next  generation  of  a  Test  Definition  Language.  SCC20  is  also 
working  on  WAVES  -  Test  Specification  Language  (IEEE  DASS  and  SCC20-ATPG 
Committees).  WAVES  is  used  to  specify  specific  waveforms  used  for  testing. 
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4.4  SCC20  Reference  Model  Test  Strategy  Layer 

The  next  higher  layer  is  the  Test  Strategy  Layer.  This  layer  specifies  in  what  sequence 
to  execute  tests  and  what  to  do  given  specific  results  from  each  test.  SCC20  has  no 
specific  active  work  items  in  this  area  and  this  is  where  our  work  fits  into  the  overall 
SCC20  architecture.  For  concurrent  engineering,  the  lower  levels  of  the  SCC20 
architecture  are  too  low  a  level  to  be  important  It  is  the  Test  Strategy  Layer  that  defines 
which  tests  are  needed.  It  is  the  test  strategy  layer  which  uses  the  data  about 

Time  to  Test 
Cost  to  Test 
Time  to  Replace  a  Part 
Cost  to  Replace  a  Part 
Part  probability  of  failure 
Test  Reliability 
Spares  Availability 
etc 

to  generate  an  optimal  test  strategy.  It  is  the  optimal  test  strategy  which  then  can  be 
used  to  compute  expected  time  to  repair,  overall  rate  of  spares  usage,  technicians 
required,  cost  of  maintenance,  impact  of  not  having  the  proper  number  of  technicians 
available,  etc.  In  our  work,  we  have  expanded  the  Test  Strategy  Layer  into  (currently) 
four  sublayers.  These  four  sublayers  will  be  described  in  more  detail  later. 

4.5  SCC20  Reference  Model  Product  Model  Layer 

The  highest  layer  in  figure  4  is  the  Product  Model  Layer.  This  layer  will  be  based  on 
VHDL  (IEEE  1076)  to  specify  the  parts  themselves.  VHDL  has  three  primary  levels  of 
detail  which  cam  be  thought  of  as  sublayers  of  the  Product  Model  Layer.  The 
sublayers  are  the  Structural  model.  Functional  model,  and  Behavioral  model.  The 
Behavioral  model  captures  the  input-output  properties  of  the  modeled  component,  and  it 
can  be  used  at  any  level  of  aggregation  of  subcomponents.  Although  VHDL  was 
originally  developed  for  use  strictly  with  semiconductor  devices,  the  behavioral  level  of 
VHDL  can  be  used  with  non-electronic  systems  as  well.  The  VHDL  Behavioral  model 
will  provide  the  primary  inputs  to  the  Test  Strategy  Layer. 

5.  IAI's  Layered  Architecture 

Figure  5  shows  the  three  layers  which  IAI  has  proposed,  and  how  those  three  layers  relate  to 
the  Product  Model  Layer  and  the  Test  Procedure  Layer  of  the  SCC20  work.  The  three  layers, 
the  dependency  model  layer,  the  ambiguity  group  layer,  and  the  fault  tree  layer  are  described 
briefly  below.  Figure  6  shows  many  current  testability  and  maintainability  analysis  tools 
which  use  dependency  models,  ambiguity  groups,  and  fault  trees.  None  of  those  tools 
interoperate  even  thought  they  use  data  which  is  quite  similar.  Our  work  will  allow  the 
developers  of  the  tools  to  write  pre  and  post  processors  which  will  convert  the  standard  neutral 
format  into  their  internal  format,  and  which  will  convert  their  internal  format  back  into  the 
neutral  format.  The  benefits  of  such  commonality  have  been  discussed  earlier  in  this  final 
report. 

5.1  Dependency  Model  Layer 

Given  the  detailed  model  defined  in  the  Product  Model  Layer,  we  can  generate  a  dependency 
model  which  relates  to  the  tests  which  are  to  be  performed  on  the  unit  under  test.  A 
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dependency  model  specifies  what  components  and  what  other  test  results  must  be  good  to 
obtain  a  good  result  from  any  specific  test.  A  dependency  model  can  be  thought  of  as  an 
abstraction  of  the  product  model  layer.  Given  a  dependency  model,  testability  tools  do  not 
need  to  be  concerned  with  the  specific  product  model  in  the  Product  Model  Layer.  Likewise, 
the  dependency  model  is  a  generic  concept  and  the  software  or  techniques  used  to  generate  the 
dependency  model  are  independent  of  how  the  model  will  be  used.  The  analogy  to  the  OS  I 
model  is  almost  perfect.  A  major  goal  of  our  effort  under  phase  1  funding  was  to  demonstrate 
the  feasibility  and  utility  of  a  standard  for  dependency  models,  and  to  prove  that  there  will  be 
significant  support  for  this  effort  from  users  and  vendors  of  testability  and  maintainability 
analysis  tools. 

A  much  more  detailed  discussion  of  dependency  models  is  presented  in  section  6  of  this  final 
report. 

5.2  Ambiguity  Groups 

The  first  output  of  tools  which  use  dependency  models  to  analyze  testability  and  maintainability 
is  ambiguity  groups.  An  ambiguity  group  means  that  given  the  tests  listed,  it  is  not  always 
possible  to  diagnose  down  to  a  single  part.  In  some  cases  a  set  of  parts  may  be  identified  as 
bad,  but  it  is  not  possible  to  reduce  the  uncertainty  down  to  a  single  component.  That  set  of 
possible  parts  is  called  an  ambiguity  group.  In  practice  it  means  that  either  one  pan  at  a  time 
must  be  replaced  and  the  system  re-tested  until  the  bad  part  is  found,  or  they  must  be  all 
replaced.  Ambiguity  groups  are  caused  by  two  primary  problems.  First,  if  there  are  not 
enough  test  points  so  that  individual  pans  cannot  be  tested,  this  causes  uncertainty  in  the  result, 
ie  an  ambiguity  group.  Second,  if  there  are  feedback  loops  so  that  a  failure  in  any  of  the  pans 
will  cause  all  the  pans  in  the  group  to  look  bad  because  they  are  not  getting  the  correct  inputs 
from  the  parts  which  provide  signals  to  them. 

We  have  defined  ambiguity  groups  as  a  separate  information  layer  because  they  are  computed 
from  the  lower  level  (dependency  model  layer)  and  they  are  used  by  the  next  layer  of 
processing  to  produce  the  optimal  test  strategy  in  the  form  of  a  fault  tree. 

5.3  Fault  Trees 

The  third  layer  we  propose  is  the  fault  tree  layer.  Fault  tree  data  specifies  the  optimal  sequence 
of  tests  for  the  diagnosis  of  a  specific  UUT.  It  will  specify  which  test  to  perform,  and  what 
operation  or  test  to  perform  next.  Many  technician  performance  aids  need  a  pre-determined 
fault  tree,  and  other  performance  aids  compute  a  fault  tree  in  real-time  using  an  internal  model 
of  the  uut.  In  the  case  of  design  tools  which  evaluate  the  testability  and  maintainability  of  a 
proposed  design,  a  fault  tree  must  be  computed  in  order  to  determine  such  values  as  the  mean 
time  to  diagnose  a  uut 

5.4  Symptom  Library  Layer 

We  are  also  evaluating  the  possibility  of  adding  a  fourth  layer  called  the  symptom  library  layer. 
This  layer  would  relate  a  set  of  predefined  symptoms  to  the  probability  that  faults  exist  in 
specific  components  of  the  UUT.  The  Air  Force  IMIS  (Integrated  Maintenance  Information 
System)  Program  has  developed  both  data  structures  and  algorithms  for  storing  and  using 
symptom  data  and  that  work  could  form  the  basis  of  the  symptom  layer.  In  many  cases,  there 
is  no  symptom  data  available.  A  piece  of  equipment  has  been  sent  to  a  depot  because  it  has 
malfunctioned  but  the  nature  of  the  malfunction  has  not  been  noted.  In  this  case  a  symptom 
layer  would  not  help.  On  the  other  hand,  in  some  cases  information  is  available  as  to  how  the 
equipment  has  malfunctioned  and  this  information  should  be  used  to  simplify  diagnosis. 
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If  we  do  add  the  symptom  library  layer,  it  would  be  used  to  alter  the  probability  of  failure  data 
based  on  symptom  information.  This  would  then,  in  turn,  be  used  to  generate  new,  or  alter 
existing  fault  trees  based  on  those  probabilities  of  failure. 

Symptom  information  could  be  derived  automatically  from  the  set  of  failure 
modes  modeled  in  the  dependency  model  if  the  dependency  model  was 
expanded  to  include  the  external  symptoms  which  would  result  from  each  of 
the  modeled  failure  modes.  Figure  7  shows  all  four  layers  in  the  proposed  architecture. 

What  we  have  called  the  symptom  library  is  similar  to  what  is  generally  called  a  fault  dictionary 
but  there  are  differences  because  a  fault  dictionary  generally  uses  the  results  of  tests  -  not 
failure  symptoms  in  the  sense  that  the  information  is  available  before  the  tests  begin.  Also,  in  a 
conventional  fault  dictionary  approach,  the  result  of  the  fault  dictionary  processing  is  a  specific 
recommendation  for  part  replacement  -  it  is  the  primary  means  of  diagnosis.  In  the  case  of 
what  we  have  proposed,  the  symptom  dictionary  is  used  only  to  alter  the  probability  of  failure 
of  components  before  testing  begins  on  the  UUT. 

6.  Dependency  Models 

Before  proceeding  with  presentation  of  the  proposed  strawman  standard  for  dependency 
models,  we  will  first  present  a  summary  of  what  dependency  models  are,  and  how  they  are 
currently  used. 

6.1  Examples 

6.1.1  Example  1  -  Very  Simple  Example 

In  dependency  models,  the  details  of  test  and  response  are  summarized  by  giving  each  test  a 
name,  and  defining  the  component  of  the  system  tested  by  that  test.  The  tl,  t2,  and  t3  shown 
below  are  tests  performed  on  units  Cl,  C2,  and  C3.  In  the  figure,  we  see  that  t4  depends  on 
component  C3  and  test  t3.  Also,  test  t3  depends  on  Cl  and  tl.  These  are  referred  to  as  first 
order  dependencies.  By  inference,  t4  also  depends  on  cl  and  tl.  This  is  an  example  of  a 
higher  order  dependency.  In  complex  circuits,  higher  order  dependencies  can  be  difficult  to 
determine. 


The  concept  of  dependency  modeling  is  very  powerful,  partly  because  it  can  be  applied 
hierarchically.  At  one  level,  components  can  be  single  integrated  circuits,  switches,  or  similar 
individual  components.  At  the  next  level,  components  can  be  larger  aggregates  such  as  a 
multiplexer,  power  supply,  floating  point  multiplier  circuit,  etc.  At  yet  the  next  level  of 
aggregation,  the  same  exact  modelling  concept  can  be  used  to  model  subsystems,  and  assess 
the  testability  of  the  system  at  that  level.  The  STAT  system  by  DETEX  has  the  capability  to 
automatically  take  models  at  one  level  and  aggregate  them  to  the  next  level. 

It  should  be  mentioned  that  dependency  models  are  not  limited  to  electronic  equipment. 
Dependence-based  testability  analysis  has  been  used  in  many  domains  with  equal  success. 
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6.1.2  Example  2.  Robot  Hand-eye  Coordination  System 


Figure  8  is  a  system  level  block  diagram  of  the  robot  hand-eye  coordination  system.  It  is  a 
system  which  IAI  has  developed  and  delivered  to  the  Army  Armament,  Research, 
Development,  and  Engineering  Center  (ARDEC),  Picatinny  Arsenal,  NJ.  The  purpose  of  the 
system  is  to  demonstrate  the  capability  for  a  robotic  system  to  catch  a  freely  thrown  ball.  The 
system  acquires  two  images  from  cameras,  stores  these  images  in  a  frame  buffer,  then 
converts  the  two  two  dimensional  images  into  one  three  dimensional  estimate  of  the  balls 
position  in  space,  then  tracks  the  object  and  develops  a  robot  trajectory  to  intercept  the  ball, 
generates  a  smooth  path  for  the  robot  to  move  along,  and  then  sends  the  smooth  path  to  the 
robot  as  a  set  of  move  commands. 

Figure  9  gives  the  first  order  dependency  data  for  the  system  of  figure  8.  This  data  was 
actually  entered  into  a  commercially  available  dependency-based  testability  analysis  tool  (STAT 
by  DETEX).  In  addition  to  the  first  order  dependencies,  data  about  the  time  to  run  each  test, 
cost  to  run  each  test,  technicians  required,  etc  was  also  entered  into  the  tool. 

An  ambiguity  group  means  that  given  the  tests  listed,  it  is  not  always  possible  to  diagnose 
down  to  a  single  pan.  In  some  cases  a  set  of  parts  may  be  identified  as  bad,  but  it  is  not 
possible  to  reduce  the  uncertainty  down  to  a  single  component.  That  set  of  possible  parts  is 
called  an  ambiguity  group.  In  practice  it  means  that  either  one  part  at  a  time  must  be  replaced 
and  the  system  re-tested  until  the  bad  part  is  found,  or  they  must  be  all  replaced.  Ambiguity 
groups  are  caused  by  two  primary  problems.  First,  if  there  are  not  enough  test  points  so  that 
individual  parts  cannot  be  tested,  this  causes  uncertainty  in  the  result,  ie  an  ambiguity  group. 
Second,  if  there  are  feedback  loops  so  that  a  failure  in  any  of  the  parts  will  cause  all  the  parts  in 
the  group  to  look  bad  because  they  are  not  getting  the  correct  inputs  from  the  parts  which 
provide  signals  to  them. 

Dependency-based  tools  provide  assistance  to  the  designer  in  identifying  ambiguity  groups, 
and  in  recommending  changes  to  the  system  to  reduce  or  eliminate  groups  of  greater  than  one 
part.  The  particular  tool  which  we  used  was  STAT  by  DETEX  Systems,  Inc  but  other 
dependency-based  tools  have  similar  outputs.  Figures  10  and  11  are  STAT  outputs  for  the 
system  of  figure  8.  The  current  circuit  is  very  bad  because  80  percent  of  all  the  parts  are  in  t  he 
same  ambiguity  group.  It  would  cost  $  5,350  to  replace  the  parts  comprising  that  single 
ambiguity  group.  The  reason  for  the  ambiguity  group  is  that  the  frame  grabber  requires  a 
"GO"  signal  from  the  Control  module,  and  the  control  module  depends  on  the  robot  to  generate 
a  sync  signal  to  it  for  its  timing.  This  creates  one  big  feedback  loop,  and  the  parts  in  that  loop 
cannot  be  individually  diagnosed  because  if  any  one  of  them  fails,  the  entire  loop  will  stop 
functioning  and  there  will  be  no  output  from  any  of  the  modules. 

Figures  1 1  gives  summary  statistics  for  the  system  as  it  is  now  designed,  and  figure  12  gives 
the  optimal  test  flow  sequence  for  the  system.  Figure  1 3  tells  the  designer  where  would  be  the 
best  points  to  modify  the  system  to  break  the  feedback  loop.  In  this  case  this  would  require  a 
test  which  supplied  a  separate  sync  signal  to  either  the  frame  grabber  or  to  the  control  module 
so  that  the  rest  of  the  system  could  continue  to  process  data.  In  figure  13,  the  *  indicates  the 
best  point  to  break  the  feedback  loop,  at  test  tl2  or  test  tl3. 

As  an  example,  we  broke  the  feedback  loop  at  t7  instead  of  at  the  recommended  tl 2  or  tl3. 
This  still  left  a  smaller  feedback  loop  between  components  8, 9,  and  10.  Figure  15  shows  the 
results,  and  as  can  be  seen  there  is  now  still  one  ambiguity  group  with  three  components,  and 
all  the  rest  have  only  one  component  each.  Figures  16,  17,  and  18  give  the  results  of  the 
system  with  the  feedback  loop  broken  at  the  recommended  tl  3.  Now  all  the  ambiguity  groups 
include  only  one  component.  Appendix  1  gives  the  complete  input  and  additional  output  for 
example  2. 


6.1.3  Example  3  -  Detailed  circuit  for  generating  signals  to  force  a  camera  to 
operate  in  non-interlaced  mode. 

Figure  19  is  a  much  more  detailed  example.  The  circuit  is  one  developed  by  IAI  and  delivered 
to  ARDEC,  Picatinny  Arsenal,  NJ.  It  is  in  fact  part  of  the  blocks  titled  Camera  1  and  Camera 
2  in  the  system  shown  in  figure  8. 

Figures  20  -  23  give  STAT  output  for  example  3.  Appendix  2  gives  the  complete  input  and 
additional  output  for  the  example. 

6.1.4  Example  4.  Example  of  Very  Detailed  Dependency  Model 

This  example  was  abstracted  from  "Test  Program  Sets  -  A  New  Approach  by  Harry  H. 
Dill,  Autotestcon  90,  San  Antonio,  TX,  Sept.  17-20,  1990. 

Consider  the  simple  circuit  depicted  in  Figure  24.  Amplifier  A1  and  its  associated 
resistors,  Rl,  R2,  and  R3,  are  configured  for  a  gain  of  two.  Resistor  R4  and  capacitor  Cl 
form  a  filter  that  is  designed  to  have  a  30dB  cutoff  of  1 .000  Hz.  Current  amplifier  A2 
presents  a  high  impedance  to  the  R4/C1  filter  when  the  output  of  the  circuit  is  loaded  with 
50  ohms.  TP0,  1,  and  2  represent  test  points,  with  PI  and  J1  representing  connector  pins. 

Let  us  now  prepare  a  detailed  dependency  model  for  this  circuit 

First,  define  the  failure  modes  that  will  require  detection.  For  purposes  of  illustration,  we 
will  define  our  failures  as  follows: 


Components 


Possible  Failure  Modes 


Rl,  R2,  R3, 
R4,  Cl 


A1,A2 


Open 

Shorted 

Out  of  tolerance  by  more  than  20% 

Incorrect  gain 
Nonlinear  operation 


Next,  prepare  labels  for  each  component  and  associated  failure  mode.  For  the  resistors  and 
capacitor,  we  will  append  the  suffix  O  to  the  component  name  for  an  open  condition  (i.e., 
RIO),  S  for  a  shorted  condition,  and  T  for  an  out  of  tolerance  condition.  For  the 
amplifiers,  we  will  use  a  G  suffix  for  gain  failures  and  L  for  linearity  failures.  Table  3  lists 
19  possible  combinations  of  failure  modes  and  components. 


TABLE  3.  EXAMPLE  UUT  LABELS  FOR 
POSSIBLE  FAILURE  MODES 

Resistors 

RIO  R2T  R4S 

R1S  R30  R4T 

R1T  R3S 
R20  R3T 
R2S  R40 

O  =  Open  Condition  G  =  Gain  Failure 

S  =  Shorted  L  =  Linearity  Failure 

T  =  Out  of  Tolerance 


Capacitor  Amplifiers 

CIO  A1G 

CIS  A2G 

C1T  AIL 

A2L 


1  2 


TABLE  4.  TESTS  TO  APPLY  TO  SIMPLE  CIRCUIT 
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Next,  design  a  series  of  tests  that  can  detect  these  failure  modes.  As  we  devise  each  test, 
we  identify  which  failure  modes  and  tests  can  be  eliminated  from  consideration  if  the  test 
passes  and  identify  the  set  of  failure  modes  and  tests  that  must  contain  the  correct  failed 
component  if  the  test  fails.  The  tests  in  Table  4,  T101  through  T107,  can  be  performed  on 
the  example  system. 

The  dependencies  listed  in  Table  4  for  tests  T101  through  T107  represent  the  first  order 
dependencies.  Higher  order  dependencies  arc  developed  by  replacing  a  dependent  test  with 
its  associated  dependencies.  For  example,  the  first  order  dependencies  shown  for  T105  are 
T104,  A2G,  and  A2L.  This  can  be  represented  as: 

T105  ->  T104,  A2G,  A2L 

Replacing  T104  with  its  dependencies,  we  have 

T105  ->  T102,  R40,  R4S,  R4T,  CIO,  CIS,  C1T,  A2G,  A2L 

Replacing  T102  with  its  dependencies,  we  have 


T105  ->  T101,  AIL,  R40,  R4S,  R4T,  CIO,  CIS,  C1T,  A2G,  A2L 

Replacing  T101  with  its  dependencies,  we  have 

T105  ->  RIO,  R1S,  R1T,  R20,  R2S,  R2T,  R30,  R3S,  R3T,  A1G,  AIL,  R40, 
R4S,  R4T,  CIO,  CIS,  C1T,  A2G,  A2L. 

By  a  similar  analysis,  the  higher  order  dependencies  for  the  remaining  tests  are: 

T105  ->  T101,  AIL,  R40,  R4S,  R4T,  CIO,  CIS,  C1T,  A2G,  A2L 

Replacing  T101  with  its  dependencies,  we  have 

T105  ->  RIO,  R1S,  R1T,  R20,  R2S,  R2T,  R30,  R3S,  R3T,  A1G,  AIL,  R40, 
R4S,  R4T,  CIO,  CIS,  C1T,  A2G,  A2L. 

By  a  similar  analysis,  the  higher  order  dependencies  for  the  remaining  tests  are: 

T107  -->  RIO,  R1S,  R1T,  R20,  R2S,  R2T,  R30,  R3S,  R3T, 

A1G,  R40,  CIS,  A2G. 

T104  ~>  RIO,  R1S,  R1T,  R20,  R2S,  R2T,  R30,  R3S,  R3T, 

A1G,  AIL  R40,  R4S,  R4T,  CIO,  CIS,  C1T. 

T103  »>  RIO,  R1S,  R1T,  R20,  R2S,  R2T,  R30,  R3S,  R3T, 

A1G.R40,  CIS. 

T102  ~>  RIO,  R1S,  R1T,  R20,  R2S,  R2T,  R30,  R3S,  R3T, 

A1G,  AIL. 
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The  objective  of  our  testing  philosophy  is  to  fault  isolate  to  the  smallest  set  of  failure  modes 
possible  using  a  minimum  number  of  tests.  To  accomplish  this  objective,  we  must  optimize 
the  sequence  in  which  tests  are  performed.  Information  content  and  test  cost  are  two  criteria 
we  can  apply  to  the  test  sequence  decision.  In  the  following  illustration,  we  define 
information  content  as  the  number  of  failure  modes  still  under  consideration  in  the  set  of 
dependencies  for  a  test,  and  we  consider  all  test  times  equal.  Also,  for  the  illustration,  we 
assume  there  is  a  single  failure  in  the  UUT. 

Using  information  content  as  our  test  selection  criteria,  we  can  examine  the  test  sequence 
that  results  if  capacitor  G  is  open.  When  we  begin  testing,  we  have  no  prior  knowledge  of 
what  failure  modes  may  exist  within  the  UUT.  We  want  to  select  the  test  in  our  set  of  tests 
that  provides  the  most  information  about  the  failure  modes  listed  in  Table  3. 

A  review  of  the  higher  order  dependencies  for  our  set  of  tests  reveals  that  T105  of  Table  4 
will  check  the  existence  of  every  failure  we  are  required  to  detect,  and  furthermore,  no 
other  test  in  our  set  of  tests  can  provide  this  much  information;  therefore  we  perform  T105 
first.  (Because  CIO  is  in  the  dependency  set  for  T105  and  CIO  is  the  failure  mode  on  the 
UUT,  T105  will  fail.) 

In  performing  T105,  we  have  accomplished  two  objectives: 

(1)  We  have  determined  that  the  UUT  is  indeed  faulty  and 

(2)  We  have  defined  the  set  of  failure  modes  containing  the  actual  UUT  failure. 

The  set  of  failure  modes  defined  is  the  dependency  list  for  T105.  Given  that  all  failure 
modes  defined  for  this  UUT  are  equally  likely  and  that  each  test  in  our  set  of  tests  has  the 
same  cost,  the  most  efficient  way  to  isolate  the  actual  failure  mode  in  the  set  of  failure 
modes  defined  by  T105  is  to  select  a  test  that  can  eliminate  half  of  the  T105  dependency 
elements. 

T101  is  the  best  test  to  do  next  because  10  of  the  T101  dependencies  are  identical  to  those 
of  T105.  If  T101  fails,  then  the  intersection  of  the  dependency  sets  for  T101  and  T105 
must  contain  the  failure  mode.  If  T101  passes,  then  the  T105  dependencies  minus  the 
T101  dependencies  must  contain  the  failure. 

This  type  of  optimization  process  continues  until  the  fault  has  been  identified. 

6.2  Categories  of  Tests 

The  examples  above  described  what  are  called  functional  tests,  but  there  are  other  classes  of 
tests  which  need  to  be  considered  in  a  neutral  format  which  must  meet  "every"  application 
requirement. 

A  good  description  of  test  categories  was  described  in  "System-Level  Diagnostics: 
Simplifying  Complexity,"  by  Dr.  William  R.  Simpson  of  ARINC.  His  taxonomy  is 
summarized  below. 

The  simplest  form  of  a  test  is  usually  called  a  FUNCTIONAL  TEST  The  outcome  of 
this  test  depends  on  all  components  and  signals  that  "feed"  the  test.  A  good  test  verifies 
all  components  and  signals  that  feed  the  test,  and  a  bad  test  implies  that  one  or  more  of 
these  elements  is  bad. 
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A  CONDITIONAL  TEST  is  characterized  by  having  more  than  one  set,  or  list  of 
dependencies.  These  dependency  lists,  in  turn,  depend  on  (are  conditioned  by)  an 
event.  Such  an  event  may  be  a  scale-setting,  a  bit  selection,  mode  of  operation,  etc. 

An  ASYMMETRIC  TEST  is  a  special  case  of  a  conditional  test  in  that  it  uses  the 
dependency  list  as  a  function  of  the  test  outcome.  There  are  three  types  of  asymmetric 
tests. 

Positive  Inference  -  A  test  the  provides  usable  information  only  when  the 
outcome  is  good.  A  bad  test  yields  no  information. 

Negative  Inference  -  A  test  the  provides  usable  information  only  when  the 
outcome  is  bad.  A  good  test  yields  no  information. 

Fully  Asymmetric  -  A  test  that,  when  the  test  outcome  is  good  the  inference  is 
drawn  from  one  dependency  list,  and  when  the  output  is  bad  the  inference  is 
drawn  from  a  different  dependency  list. 

A  LINKED-OUTCOME  TEST  is  a  test  where  the  result  of  one  test  reduces  the 
dependency  relationships  for  another  test. 

A  SPECIAL  TEST  is  any  test  which  does  not  fall  into  any  of  the  above  categories.  It 
does  not  normally  monitor  the  functional  health  of  a  system,  rather  it  provides  insight 
into  the  possible  failures  within  a  system. 

6.3  Test  Data 

In  addition  to  dependency  data,  data  is  required  regarding  the  tests  themselves.  The  parameters 
of  interest  include 

Time  to  perform  test 
Cost  to  perform  test 
Reliability  of  the  test 
Test  groups 

Test  groups  are  groups  of  tests  which,  for  physical  reasons,  should  be 
performed  together.  A  typical  test  group  would  occur  because  of  the  need  to  set 
up  special  equipment .  Once  that  equipment  is  set  up,  all  relevant  tests  which 
could  be  performed  with  that  equipment  should  be  made  at  that  time. 

Sequence  groups 

Sequence  groups  are  groups  of  tests  which  must  be  performed  in  a  specific 
order  because  of  the  Unit  Under  Test's  requirements  relating  to  the  machine 
state  required  to  run  a  particular  test 
Technician  skill  level  required  to  run  a  test 
Manpower  required  to  run  tests 
Test  equipment  required  to  run  a  particular  test 

6.4  Component  Data 

Our  maintenance  tools  can  also  use  a  priori  knowledge  about  the  components  of  a 
system.  The  most  important  data  item  is  the  expected  failure  rai^s  of  ihe  diffcient 
components.  If  a  given  component  is  much  more  likely  to  fail  than  other  components, 
tests  which  isolate  that  component  should  in  general  be  done  first. 
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Data  on  part  failures  from  equipment  returned  from  field  use,  and  Retest  OK  data 
should  also  be  included. 

6.5  Desired  Results 

Given  the  required  dependency  data,  data  on  the  tests,  and  component  data  ,  dependency 
model-based  systems  can  generate  the  following  type  of  information: 

An  optimized  fault  tree 
Fault  Coverage 

Ambiguity  group  evaluation  in  terms  of  numbers  and  sizes  of  ambiguity  groups,  and 
the  specific  components  in  each  group 
Probability  of  failure  of  an  ambiguity  group 

Suggested  points  to  break/contnol  feedback  loops  to  reduce  ambiguity  groups 
Expected  false  alarm  rates 
Topological  Complexity  (TC)  Chart 

a  calculated  value  that  reflects  the  model's  complexity  based  on  the  number  of 
tests,  dependencies  per  test,  and  dependents  per  test. 

Expected  average  time  to  diagnose  faults 
Time  to  diagnose  any  specific  fault 

The  optimized  fault  tree  defines  the  diagnosis  sequence  which  a  technician  should  use  to 
diagnose  the  UUT.  The  definition  of  optimal  may  be  selected  by  the  user  by  defining  the 
relative  weights  of  each  of  the  test  parameters.  As  and  example,  the  user  may  specify  the 
relative  importance  of 

cost  to  test 
time  to  test 

usage  of  critical  test  equipment 

risk  associated  with  making  test  (to  equipment  or  operator) 

With  these  importance  parameters  specified,  the  fault  tree  which  is  generated  will  be 
optimal  with  respect  to  the  defined  parameters  and  their  relative  weights.  Optimality  includes 
consideration  of  all  of  the  parameters  which  the  system  has  data  for. 

Results  such  as  expected  time  to  diagnose  a  problem,  expected  cost  to  diagnose  a  problem,  and 
size  of  ambiguity  groups  are  valuable  in  predicting  life  cycle  support  costs.  "What  if'  analyses 
can  be  done  by  adding  test  points  and  observing  the  changes  in  these  parameters.  Certain  tests 
may  require  technicians  with  higher  levels  of  training  and  "what  if’  tests  can  be  done  to 
evaluate  the  impact  if  these  technicians  are  not  available,  or  if  those  tests  are  excluded  entirely 
from  the  test  plan. 

As  field  data  is  available  on  any  UUT  type,  this  data  can  be  entered  into  the  system  and  used  to 
update  the  data  listed  above.  This  will  result  in  immediate  improvements  in  the  optimal  test 
strategy,  and  improvements  in  availability  estimates,  and  in  maintenance  cost  estimates,  etc. 


7.  Formal  Model 

There  are  two  problems  associated  with  developing  a  formal  neutral  data  interchange  format. 
First  a  formal  data  model  is  required  so  everyone  knows  what  the  data  means  and  how  each 
data  item  relates  to  each  other  data  item.  Second,  a  data  transfer  format  must  be  selected.  This 
second  problem  is  trivial  but  we  mention  it  for  completeness. 
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7.1  EXPRESS 


The  approach  taken  the  define  the  formal  data  model  was  to  use  the  International  Standards 
Organization  (ISO)  Standard  called  EXPRESS.  EXPRESS  is  an  international  standard  for 
modeling  information.  EXPRESS  takes  the  view  that  a  thing  (entity)  is  defined  in  terms  of  its 
attributes,  which  are  represented  by  other  things.  A  point,  for  example,  might  be  defined  in 
terms  of  three  real  numbers.  Names  are  given  to  the  ingredients  which  contribute  to  the 
definition  of  a  thing.  Thus,  for  a  point  the  three  real  numbers  might  be  named  x,  y,  and  z.  A 
relationship  of  sorts  is  established  between  the  thing  being  defined  and  the  attributes  that  define 
it. 

Every  Entity  declared  in  an  EXPRESS  schema  is  considered  independent.  There  is  no 
provision  in  an  entity  declaration  to  closely  couple  it  with  another  entity  from  a  usage  point  of 
view.  Rules  can  be  written  to  effect  dependence,  but  the  intent  is  to  make  every  entity  an 
independent  resource. 

There  are  several  other  formal  data  modeling  approaches  but  we  chose  EXPRESS  because  it  is 
what  is  being  used  by  the  PDES/STEP  Committee  and  we  felt  that  would  make  our  work  even 
more  compatible  with  that  much  larger  program.  In  addition,  NIST  has  developed  an 
EXPRESS  compiler  which  takes  an  EXPRESS  "program"  and  complies  it  into  an  Oracle 
database  automatically.  The  NIST  system  also  generates  code  automatically  to  populate  that 
database  from  a  data  stream  encoded  using  ISO  CD  10303  (Product  Data  Representation  and 
Exchange  Clear  Text  Encoding  of  the  Exchange  Structure). 

The  following  pages  present  the  Strawman  EXPRESS  Model  we  have  generated  for 
Dependency  Data.  It  is  intended  only  as  a  Strawman,  and  many  improvements  and 
refinements  will  be  required  before  the  model  is  sufficiently  complete  to  be  adopted  as  a 
standard.  On  the  other  hand,  it  does  crystalize  the  general  concept,  clarify  what  types  of  data 
should  be  included  in  the  model,  and  it  does  provide  a  very  concrete  place  for  the  AI-ESTATE 
Committee  of  SCC20  to  begin  its  formal  evaluation  of  the  proposal. 

This  final  report  does  not  provide  background  on  data  modeling  itself  because  that  would  be  a 
several  hundred  page  document  in  itself.  The  reader  is  referred  to  the  many  books  on  the 
subject,  such  as  "On  Conceptual  Modelling, "  Edited  by  Michael  Brodie,  John  Mylopoulos, 
and  Joachim  Schmidt,  Springer-Verlag,  1986.  The  actual  model  presented  in  the  following 
pages  is  mostly  self  explanatoiy.  A  brief  summary  of  the  highlights  is  presented  below. 

7.2  EXPRESS  model  of  uut_test 

The  EXPRESS  model  of  uut_test  is  given  below. 

ENTITY  uut_test; 

-attributes 
test  name:  string 

-relationships 

has_re sources:  SET  OF  resources; 
has_priorities:  priorities; 

_ has_uut:uut; 

END_ENTTTY; 


ENTITY  priorities; 

-attributes 
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time_factorreal; 

cost_factorreal; 

reliability_factor:real; 

END_ENTTTY; 


ENTITY  uut; 

--attributes 

uut_name:stting; 

explanation :  string ; 

serial_number:integer, 

reference_docs:  SET  OF  integer, 

uut_input_#:  SET  [1,#]  OF  integer, 

uut_output_#:  SET  [1,#]  OF  integer, 

-relationship 

_ has_components:  SET  [1,#]  OF  component; 

END_ENTTTY; 


ENTITY  resources  SUPERTYPE  OF  equipment,  technician; 
—attributes 

has_equipment:  SET_OF  equipment; 
has_technician:  SET  OF  technician; 
END_ENTITY; 


ENTITY  equipment  SUBTYPE  OF  resources; 
-attributes 

_ namerstring; 

ENDJENTITY; 


ENTITY  technician; 

— attributes 
skilljevel  :integer, 
END_ENTITY; 


ENTITY  component; 

-attributes 

component_id:  integer, 

—relationships 

has_aspect:  SET  [1,#]  OF  component_aspec t; 
has_replacement _group:  SET  OF  component_id; 

_ has_failure _group:  SET  OF  component_id; 

END_ENTITY; 


ENTITY  component_aspect; 

-attributes 

aspect_description:  string; 
aspect_id:integer, 
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aspect_inputs:  SET  [1,#]  OF  aspect_input; 
aspect_outputs:  SET  [1,#]  OF  aspect_output; 

--relationships 

has_component_type :  component_type; 

has_conditional_connections:  SET  £1,#]  OF  condi tional_connect; 
END.ENTITY; 


ENTITY  aspect_input; 

--attributes 

_ aspect_input:integer, 

END_ENTITY; 


ENTITY  aspect_output; 

-attributes 

aspect_output:  integer, 
END_ENTITY; 


ENTITY  component_type; 

-attributes 

component_type:  integer, 
component_name:  string; 
inventory:  integer, 
usage_rate:  integer, 
time_to_replace:integer, 
cost_to_replace:  integer, 
instructions_to_replace:document_ptr, 
END_ENTTTY; 


ENTITY  condi  tional^connect; 

-relationship 

has_switch_settings:  SET  OF  switch_setting; 
has_good_input_connection/test:  SET  [1,#]  OF  input_connection/test; 
has_good_output_connection/test:  SET  [1,#]  OF  output_connection/test; 
has_bad_input_connection/test:  SET  [  1  ,#]  OF  input_connection/test; 
has_bad_output_connection/test:  SET  [1,#]  OF  output_connection/test; 
END_ENHTY, 


ENTITY  switch_setting: 

-attributes 

switch_setting:integer, 
switch_name :  string; 
END_ENTITY; 


ENTITY  input_connection/test; 

has_test:  test; 

has_input_from_component :  component_output 
OR 


20 


has_input_from_uut_input:  uut_input_# 
OR 

has_input_from_uut_output:  uut_output_#; 
END_ENTITY ; 


ENTITY  output_connection/test; 

has_test:  test; 

has_output_to_component:  component_input 

OR 

has_output_to_uut_input:  uut_input_# 

OR 

has_output_to_uut_output:  uut_output_#; 
END_ENTITY; 


ENTITY  test; 

-relationships 

has_test_attributes:  test_attributes; 
has_immediate_predecessor:  test; 
has_test_group:  SET  OF  test; 
has_predecessors:  SET  OF  test; 
END_ENTITY; 


ENTITY  test_parameters; 

-attributes 

instructions_to_perform_test:  pointer_to_text; 
probability  _of_false_negative; 
probability  _of_false_positive; 

manpower_reqd_to_perform_test:  SET  [  1  ,#]  OF  integer, 
test_name:string; 

cost_to_perform_test:  integer:  integer, 
time_to_perform_jest:  integer, 
risk:  integer, 

ENTLENTITY; 


The  following  sections  describe  the  model,  starting  with  the  uut_test.  We  should  make  it  clear 
to  the  reader  that  the  following  model  is  a  proposed  strawman  to  begin  the  process  of  defining 
a  standard.  It  is  by  no  means  intended  as  a  final  model  ready  for  adoption.  The  strawman 
should  get  users  and  vendors  interested  in  developing  a  standard,  and  should  convince  them 
that  a  standard  is  feasible. 


uut_test  uut_test  is  composed  of  three  sub  entities,  resources,  priorities,  and  the  uut 
itself 

7.2.1  resources 

The  ENTITY  resources  identifies  the  resources  available  for  a  particular  uut  test.  Resources 
include  the  test  equipment  and  technicians  available.  Looking  at  the  ENTITY  resources,  it 
is  composed  of  two  ENTITIES  called  equipment  and  technicians.  From  the  formal  data 
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modeling  point  of  view,  equipment  and  technicians  are  subtypes  of  resources.  In  formal 
data  modeling  jargon,  equipment  is  a  resource,  and  technician  is  a  resource.  Note  that 
the  equipment  and  technicians  required  for  a  particular  test  are  modeled  as  part  of  the 
ENTITY  test 

7.2. 1.1  equipment 

The  ENTITY  equipment  currently  consists  of  only  a  name  which  identifies  the  particular 
available  piece  of  equipment.  This  is  probably  not  general  enough  and  more  work  will  be 
required  to  allow  specification  of  a  capability  or  class  of  equipment  in  addition  to  a 
specific  unique  name  for  the  available  equipment 

7.2.1.2  technician 

The  ENTITY  technician  contains  only  one  attribute,  which  is  skill_level.  This  indicates 
the  minimum  skill  level  of  the  technicians  available  to  perform  the  uut_test. 

7.2.2  priorities 

The  optimum  test  strategy  depends  on  weights  assigned  to  parameters  called  test_factor, 
cost_factor,  and  reliability  factor.  It  may  be  that  in  a  given  situation,  the  time  to  get  a  piece 
of  equipment  back  on  line  is  much  more  important  than  the  cost  of  that  repair,  and  in  other 
cases  the  opposite  may  be  true.  The  three  priority  factors  allow  the  user  to  weigh  the 
importance  of  time,  cost,  and  reliability. 

7.2.3  uut 

The  uut  is  modeled  with  a  uut_name,  a  comment  string  called  explanation,  a  serial  number, 
reference  document  numbers,  and  a  list  of  inputs  and  outputs,  each  with  a  unique  number. 
Most  of  the  definition  of  uut  is  contained  in  the  ENTITY  component.  A  uut  is  composed  of 
a  SET  OF  [1,#]  of  component.  That  notation  means  that  a  uut  must  have  at  least  1 
component. 

7.2.3.1  component 

Each  unique  component  has  a  unique  identification  number  which  identifies  that 
specific  component.  In  dependency  modeling,  components  are  broken  into  aspects. 
Depending  on  the  exact  system,  these  aspects  are  viewed  as  "virtual  components ' 
or  as  component  failure  modes.  A  component  can  have  [1,#]  OF 
component_aspect  (one  or  more).  Components  also  have  a  replacement_group,  and 
a  failure  group. 

7.2.3. 1.1  rep!acement_group 

A  replacement _group  means  that  when  one  part  of  a  replacement  group  is 
replaced,  all  the  other  parts  must  also  be  replaced.  This  is  important  for 
diagnosis  because  it  means  that  there  is  no  reason  to  diagnose  below  the 
level  of  a  replacement  group  because  all  the  parts  must  be  replaced  anyway. 
A  replacement_group  is  a  SET_OF  component  _id  which  identifies  the 
group  of  components  included  in  the  replacement  group  for  this  particular 
component. 

7. 2.3.1. 2  failure_group 
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A  failure  group  means  that  when  a  particular  part  fails,  it  will  have  a  high 
probability  of  causing  the  failure  of  the  other  parts  in  the  failure  group. 
These  linked  failures  result  in  multiple  failures  which  can  be  handled  in  a 
dependency  model  based  system  if  they  are  identified  as  potential  multiple 
faults. 

7.2.3.1.3  componentaspect 

Component_aspects  have  a  description,  and  a  unique  identifier  (called  the 
"dash"  number  in  STAT  for  example).  Component  aspects  also  have  sets 
of  inputs  and  outputs  which  are  each  identified  by  a  unique  integer,  and 
each  component  has  a  component  type.  The  most  important  part  of  the 
formal  model  for  component  aspects  is  the  ENTITY 
conditional_connection.  A  component  is  modeled  as  having  a  SET  [1,#] 
OF  conditional_connections.  In  dependency  modeling,  the  dependency  of  a 
component  may  be  a  function  of  switch  settings,  initializations,  external 
equipment  attached,  etc.  There  may  be  different  dependencies  for  each 
case,  and  these  are  modeled  as  conditional_dependencies.  A  component 
must  have  at  least  one  conditional  dependency,  which  means  its 
dependencies  are  not  influenced  by  other  factors. 

7.2.3.1.3.1  componenttype 

Component_type  models  the  characteristics  of  the  particular  component 
independent  of  this  particular  component  aspect,  function,  or  position  of 
this  component  in  the  uut  Component_type  models  the  data  generic  to 
the  component  itself.  These  include  the  component  name,  a  unique  type 
number,  the  number  of  those  parts  currently  in  inventory,  the  usage 
rate,  time  to  replace  the  part,  cost  to  replace  the  part,  and  a  pointer  to  the 
documentation  on  how  to  replace  the  part. 

7.2.3. 1.3.2  condiUonaI_connection 

A  conditional_connection  can  be  thought  of  as  a  "box"  in  a  dependency 
model  diagram.  That  box  has  a  set  of  switch  settings  which  define  the 
particular  state  of  the  switch  settings,  initializations,  etc.,  which  give 
rise  to  the  specific  conditional  dependency  in  question.  Then  the  "box" 
has  SET[1,#]  OF  inputs  and  SET  [1,#]  OF  outputs.  Each  such  input  or 
output  can  have  a  test  associated  with  that  connection.  The  actual 
interconnection  of  the  "box"  to  its  inputs  and  outputs  is  modeled  in  the 
ENTITIES  good_input_connection/test,  good_output_connection/test, 
bad_input_connection/test,  bad_output_connection/test,  along  with 
attributes  concerning  the  test  itself.  The  reason  why  the  good  and  bad 
distinction  is  required  is  that  in  some  cases,  tests  are  asymetric.  If  a  test 
is  good,  certain  information  is  obtained,  but  if  the  test  is  bad,  a  different 
set  of  information  is  obtained.  An  example,  from  Dr.  Randy  Simpson 
of  ARINC,  would  be  an  oil  pressure  light  on  a  car.  If  the  light  is  on 
(bad  result)  it  says  that  there  is  a  fault  in  the  engine,  but  if  the  light  is  off 
(good  result),  it  gives  virtually  no  information  about  the  engine.  The 
light  could  be  bad,  the  electrical  system  could  be  bad,  the  oil  pressure 
sensor  could  be  bad,  etc.  In  most  cases,  however,  the  dependencies 
related  to  a  good  result  and  a  bad  result  will  be  identical. 

7. 2.3.1. 3.2.1  input_connection/test 
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Input_connection/test  has  ENTITY  test  which  contains  details  about 
the  test  itself  which  is  associated  with  that  particular  input 
connection.  The  connection  itself  is  modeled  as  one  of  three 
possibilities  -  connection  to  another  component_aspect;  connection 
to  a  uut_input;  or  connection  to  a  uut_output  These  entities  specify 
the  exact  connection  of  this  particular  conditional_connect‘s  inputs 
to  the  other  component  aspects  in  the  model. 

7. 2.3.1. 3.2. 2  output_connection/test 

Output_connection/test  has  ENTITY  test  which  contains  details 
about  the  test  itself  which  is  associated  with  that  particular  output 
connection.  The  connection  itself  is  modeled  as  one  of  three 
possibilities  -  connection  to  another  component_aspect;  connection 
to  a  uut_input;  or  connection  to  a  uut_output  These  entities  specify 
the  exact  connection  of  this  particular  conditional_connect's  outputs 
to  the  other  component  aspects  in  the  model. 

7. 2.3. 1.3.2. 1.1  test 

A  test  is  composed  of  test_parameters  which  define  the  particular 
test  and  its  sequence  requirements. 

7.2.3.1.3.2. 1.1.1  testparameters 

Test  parameters  consist  of  ENTITY’S  which  include 
instructions  to  perform  the  test,  probability  of  false  negative, 
probability  of  false  positive,  manpower  required  to  perform 
test,  equipment  required  to  perform  test,  etc. 

7.2.3. 1.3. 2. 1.1. 2  immediatepredecessor 

In  many  cases,  tests  must  be  performed  in  a  specific 
sequence,  generally  as  a  result  of  the  state  of  the  system 
under  test.  Test  sequences  are  modeled  by  defining  exactly 
zero  or  one  specific  predecessor  tests.  Since  each  test  can 
have  a  predecessor  test,  this  is  sufficient  to  define  the 
sequence  of  all  tests  if  that  is  required. 

7.2.3.1.3.2.1.1.3  test_group 

It  is  often  the  case  that  tests  should  be  done  in  groups  as  a 
result  of  physical  access,  test  equipment  setup,  or  other 
factors.  Within  a  test  group,  the  exact  sequence  of  tests  is 
unspecified  but  once  ore  of  the  tests  is  done,  the  others 
should  be  done  before  any  other  tests.  Specification  of  a  test 
group  is  normally  for  efficiency  purposes. 


7.2. 3.1. 3.2. 1.1.4  predecessors 

The  ENTITY  predecessors  defines  a  set  of  tests  which  must 
be  done  before  this  test,  but  the  order  of  those  tests  is 
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unimportant  except  that  they  all  precede  the  test  for  which 
this  data  applies. 


8.  Experimental  Software 

If  IAI  is  successful  in  developing  a  standard  data  model  and  interchange  format  for  dependency 
model  data,  ambiguity  group  data,  and  fault  tree  data,  then  conforming  models  for  most 
military  and  even  non-military  systems  will  be  developed.  This  means  that  a  wide  range  of 
tools  will  be  able  to  be  developed  which  use  that  data.  Figure  26  shows  some  of  the  tools 
which  might  be  developed  independently  by  companies.  We  emphasize  that  without  standards, 
it  would  not  be  economically  viable  to  produce  such  products  because  there  would  not  be  a 
large  enough  market.  By  developing  an  open  system  architecture,  we  open  up  the  possibility 
of  not  one  but  many  commercial  products  which  use  or  produce  conforming  data. 

We  will  describe  the  tools  shown  on  figure  26  in  groups. 

8.1  Tools  to  produce  better  dependency  models 

Dependency  models  can  be  simple  and  can  be  generated  almost  automatically,  or  they  can  be 
very  sophisticated  and  require  considerable  expertise.  Simple  models  will  not  have  the 
resolution  of  a  more  complex  model.  Tools  which  apply  artificial  intelligence  could  be 
developed  to  generate  good  models,  or  improve  existing  models.  These  artificial  intelligence 
tools  could  be  rule-based,  or  they  could  function  using  a  group  technology  approach,  or  they 
could  use  a  combination  of  these  approaches.  In  either  case  their  input  would  be  the  product 
model  of  the  uut  (plus  any  existing  dependency  model)  and  their  result  would  be  an  improved 
dependency  model. 

Tools  which  use  field  data  to  improve  dependency  models  would  be  extremely  useful  and  are 
entirely  feasible.  These  improved  models  would  then  be  loaded  into  on-line  technician 
maintenance  aids  and  improved  diagnosis  would  immediately  result 

8.2  Tools  to  produce  better  physical  circuit  layouts 

Given  a  dependency  model  and  ambiguity  group  results,  it  would  be  possible  to  develop  tools 
which  would  optimize  the  mechanical  layout  of  a  system.  As  an  example,  consider  a  quad 
logic  gate,  op  amp,  or  similar  component.  There  are  failure  modes  where  all  four  gates  will 
fail,  resulting  in  four  failures.  Since  most  diagnosis  tools  assume  a  single  failure,  the  result 
can  be  wasted  time  and  unnecessary  replacements.  If  there  are  several  identical  gate  packages 
in  the  circuit,  gate  selection  could  be  optimized  to  reduce  the  probability  of  false  diagnosis  due 
to  this  problem. 

Test  points  can  be  physically  placed  so  that  groups  of  tests  can  be  performed  together,  saving 
time.  A  tool  to  perform  this  type  of  optimization  could  be  developed. 

8.3  Test  Sequence  Optimization 

Tools  could  be  developed  to  perform  increasingly  capable  optimization  of  the  test  sequence. 
Such  tools  would  use  the  dependency  model  as  input  and  output  fault  trees.  The  optimization 
could  use  additional  data  such  as  historical  data  for  that  specific  uut  (serial  number),  historical 
data  for  that  type  of  uut,  or  it  could  perform  the  optimization  faster  than  other  tools,  etc. 

8.4  Technician  Performance  Aids,  and  Training  Aids 
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There  are  several  military  systems  which  use  some  form  of  fault  tree  as  a  data  base  to  provide 
on-line  aid  to  a  technician  performing  equipment  diagnosis.  If  there  were  a  standard  fault  tree 
format,  these  tools  could  interoperate.  Tools  could  be  built  which  provide  computer-based 
training  using  the  fault  tree  information  as  a  database  representing  the  correct  diagnosis 
strategies. 

8.5  Other  types  of  tools 

Tools  could  be  developed  to  generate  ATLAS  code  directly  from  fault  trees.  Software  to 
provide  on-line  TRD's,  or  for  publishing  conventional  paper  TRD’s  would  be  more  feasible 
than  is  the  case  today  because  more  systems  would  have  conforming  representations  from 
which  the  required  data  could  be  easily  derived. 

The  above  tools  have  been  discussed  to  show  that  there  are  many  opportunities  for  developing 
commercial  products  which  exploit  the  proposed  standards.  The  feasibility  of  these  tools 
depends  on  the  number  of  systems  to  which  they  could  be  easily  applied,  and  this  greatly 
increases  if  a  National  Standard  neutral  format  could  be  developed  for  the  required  data. 

9.  IAI's  Diagnosis  Apprentice 

As  part  of  this  contract.  Intelligent  Automation,  Incorporated  has  developed  software  which  we 
call  the  Diagnosis  Apprentice.  This  software  demonstrates  one  of  the  types  of  tools  which  will 
function  using  the  proposed  standards. 

The  Diagnosis  Apprentice  provides  a  hypermedia  front  end  to  a  Test  Requirements  Document, 
and  also  demonstrates  many  features  which  would  be  usable  during  concurrent  engineering 
activities  to  improve  the  testability  and  maintainability  of  a  system.  These  features  are  similar 
to  the  features  provided  by  the  commercial  tool  STAT  by  DETEX  Systems,  Incorporated. 
STAT  is  a  dependency  model  based  testability  analysis  tool  which  generates  a  set  of  paper 
reports,  including  a  fault  tree.  With  improvements  to  those  algorithms,  and  with  state  of  the  art 
hardware,  our  dependency  model  based  system  will  serve  as  a  real-time  technician’s  aid  for  use 
during  equipment  diagnosis,  as  well  as  a  tool  for  performing  testability  and  maintainability 
analysis  during  the  design  of  a  system.  In  both  of  these  applications,  the  user  interface  will  be 
an  intuitive,  flexible,  hypermedia  based  interface.  Even  in  the  current  version  of  the  tool,  we 
have  interfaced  the  diagnosis  aid  to  a  computer  version  of  the  maintenance  manual  so  that  if  a 
particular  operation  requires  reference  to  the  manual,  the  user  will  have  immediate  access  to  that 
manual  on-line  through  a  hypermedia  interface. 

9.1  Fault  Tree 

The  Diagnosis  Apprentice  displays  the  fault  tree  for  any  UUT.  See  figure  27.  The  menu 
visible  in  the  lower  right  is  called  the  tool  set  and  it  can  be  moved  anywhere  on  the  screen,  or 
closed  entirely.  Once  closed,  it  can  always  be  re-opened  using  the  tool  set  icon  in  the  upper  left 
comer  of  the  screen.  The  tool  set  functions  allow  the  fault  tree  to  be  displayed  in  several 
different  formats  (vertical,  horizontal,  or  parallel).  Other  tool  set  options  are 

continuation  sheet 
test  diagram 
ATLAS  source  code 
ATLAS  flow  chart 
functional  flow 
test  information 
diagnostic  flow  table 
dependency  model 
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9.1.1  Continuation  Sheet 


A  continuation  sheet  is  terminology  from  a  Test  Requirements  Document  (TRD).  It  refers  to 
explanatory  text  about  a  given  test.  Figure  30  shows  an  example  of  a  continuation  sheet.  A 
continuation  sheet  refers  to  a  specific  test  -  the  test  can  be  determined  from  a  menu  which 
appears  if  the  continuation  sheet  option  is  selected  from  the  tool  set.  If  no  menu  selection  is 
made,  the  current  test  is  assumed  and  that  continuation  sheet  is  displayed. 

9.1.2  Test  Diagram 

The  test  diagram  shows  the  interconnection  of  any  required  test  equipment.  Figure  31  is  an 
example  of  a  test  diagram.  The  specific  test  is  selected  exactly  as  in  the  case  of  a  continuation 
sheet. 


9.1.3  ATLAS  Source  Code,  and  ATLAS  Flow  Chart 

Many  of  the  tests  called  out  in  the  fault  tree  use  automatic  test  equipment.  This  automatic  test 
equipment  is  programmed  in  a  language  called  ATLAS.  The  technician  may  need  to  see  the 
actual  ATLAS  code  to  fully  understand  what  test  is  being  performed  and  our  system  will 
display  both  a  flow  chart  of  the  ATLAS  code,  and  the  code  itself.  In  both  cases,  the  test  of 
interest  is  either  the  current  test,  or  a  test  selected  from  a  menu  (this  is  identical  to  the 
continuation  sheet  test  selection). 

9.1.4  Diagnostic  Flow  Table 

Figure  34  shows  the  Diagnostic  Flow  Table.  This  is  a  small  window  which  can  be  moved 
anywhere  on  the  screen,  or  closed.  For  any  test,  it  displays  the  next  test  or  repair  step  given  a 
good  or  bad  result  of  the  current  test.  If  the  Good  icon  is  selected,  the  current  test  becomes 
die  sjjecified  test  (in  the  example  on  figure  34,  the  new  current  test  will  be  T309-1.)  If  the  Bad 
icon  is  selected,  the  current  test  is  changed  similarly.  If  either  the  good  or  bad  test  result 
indicates  a  repair  operation,  the  correct  pages  in  the  repair  manual  will  automatically  be 
displayed.  The  linkage  to  the  repair  manual  is  discussed  later  in  this  report 

9.2  Notebook 

For  any  test,  the  system  designer  or  the  technician  can  open  a  notebook  and  make  notes  about 
that  particular  test  The  notes  are  specific  to  that  particular  test.  Anything  can  be  entered  into 
the  notebook,  or  things  can  be  copied  into  the  notebook.  Figures  35,  36,  and  37  all  show  the 
notebook  opened.  The  notebook  can  be  moved  to  any  point  on  the  screen,  or  can  be  expanded 
in  size  with  an  expansion  icon  which  is  barely  visible  on  the  upper  right  comer  of  the  notebook 
shown  in  figure  37.  Figure  28  shows  that  test  T1010  has  been  selected  by  holding  down  the 
mouse  button  with  the  arrow  cursor  on  the  test.  This  opens  a  menu  in  which  the  notebook  is 
one  option,  and  the  notebook  can  then  be  selected.  The  notebook  can  also  be  opened  from  the 
dependency  model  diagrams. 

9.3  Time  to  Go  and  Cost  to  Go 

For  any  test,  the  expected  time  to  go  to  complete  the  test,  and  the  expected  cost  to  complete  the 
test  can  be  displayed.  This  option  can  be  opened  from  the  test  related  menu  shown  in  figure 
28,  or  from  the  dependency  model  related  menus. 

9.4  Dependency  Model 
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Our  Diagnosis  Apprentice  is  a  dependency  model  based  tool  and  it  is  able  to  display  the 
dependency  model  of  the  UUT  at  any  time.  Figure  32  shows  a  dependency  model  displayed 
on  the  screen.  The  black  items  are  component  aspects  and  they  are  identified  by  the  I###-# 
notations  inside  the  box.  The  tests  are  identified  with  T###-#  numbers.  Because  the  user 
interface  is  hypermedia-based,  both  the  test  numbers  and  the  component  aspect  numbers  are 
active  in  that  selecting  those  values  opens  lower  level  windows  or  moves  the  system  to  other 
displays. 

9.4.1  Ambiguity  Group  Information 

An  ambiguity  group  represents  the  best  diagnosis  that  can  be  done  with  the  specified  tests  and 
test  points.  It  is  often  not  possible  to  diagnose  down  to  a  single  part,  and  in  many  cases,  a 
diagnostic  procedure  will  be  able  to  identify  the  failed  part  as  one  of  a  group  of  several  parts. 
In  this  case,  either  all  the  parts  must  be  replaced,  or  a  choice  must  be  made,  that  part  replaced, 
and  the  system  retested.  The  groups  of  possibly  bad  parts  is  called  an  ambiguity  group. 
Clearly  large  ambiguity  groups  have  a  major  negative  impact  on  the  cost  and  time  to  repair  a 
faulty  system.  For  any  part,  the  Diagnosis  Apprentice  will  display  the  ambiguity  group 
containing  that  part.  It  will  often  but  not  always  consist  of  one  part  The  top  window  in  figure 
30  shows  an  ambiguity  group  for  part  1319-1.  On  the  upper  left  of  the  window,  an  icon 
allows  display  of  all  the  tests  which  test  that  part.  Selecting  that  test  will  result  in  the  correct 
point  in  the  fault  tree  which  contains  the  selected  test  to  be  displayed. 

In  addition  to  the  ambiguity  group,  the  window  on  the  top  of  figure  33  also  indicates  the  cost  to 
replace  all  the  parts  in  the  ambiguity  group,  and  the  time  to  replace  all  the  parts  in  the  ambiguity 
group. 

The  designer  can  use  the  Diagnosis  Apprentice  to  perform  "what  if'  analysis  to  determine  the 
benefits  from  adding  additional  test  points,  to  breaking  feedback  loops,  etc.  This  is  one  of  the 
primary  uses  of  existing  dependency  model  based  tools,  and  our  system  will  make  that 
capability  easier  to  use,  and  the  standards  we  are  working  toward  will  make  the  produce  all  the 
more  cost  effective  and  practical  to  use. 

9.4.2  Test  Cross  Reference 

As  shown  in  the  window  in  the  lower  right  of  figure  33,  the  system  will  also  display  the 
number  and  size  of  ambiguity  groups  which  are  in  the  dependency  list  of  a  given  test. 
Selecting  the  test  from  the  window  specifically  identifies  the  groups  and  selecting  the  ambiguity 
group  icon  displays  the  ambiguity  group  details  as  described  above. 

9.5  Additional  Features 

The  current  version  of  the  Diagnosis  Apprentice  was  coded  as  an  example  of  the  type  of  system 
which  could  be  implemented.  With  follow-on  funding  we  will  be  able  to  implement  all  of  the 
features  in  current  systems  such  as  STAT  and  STAMP  for  use  during  design,  and  all  of  the 
features  of  POINTER  or  GADDS  for  use  as  a  real-time  technician's  aid  in  performing 
diagnosis  and  repair. 

9.6  Interface  to  Maintenance  Manuals 

Figures  35  to  41  show  example  screen  shots  from  the  automated  maintenance  manual  which 
IAI  has  interfaced  to  the  Diagnosis  Apprentice  so  that  when  specific  instructions  are  required 
by  the  technician,  they  will  be  immediately  available  without  having  to  find  and  use  paper 
manuals.  It  should  be  noted  that  the  software  which  implements  these  functions  was 
developed  under  funding  from  the  U.S.  Department  of  Education,  and  from  the  U.S.  Naval 
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Air  System  Command.  Its  adaptation  for  use  with  the  Diagnosis  Apprentice  was  done  as  part 
of  the  subject  SBIR  contract 

Some  of  the  features  of  the  user  interface  are  described  briefly  below. 

9.6.1  Outline 

Our  manual  display  system  provides  several  tools  to  allow  the  user  to  move  easily  and  naturally 
through  the  document  so  that  they  will  always  know  where  they  are,  and  how  to  get  to  any 
specific  point.  This  is  an  important  feature  because  research  has  shown  that  one  problem  with 
hypermedia  systems  is  that  users  "get  lost"  in  the  sense  that  they  are  not  sure  where  they  are  or 
how  to  get  back  to  any  previous  point.  As  shown  in  figure  35,  a  table  of  contents  is  visible  on 
the  upper  left  of  the  screen.  This  field  is  scrollable,  and  also  can  be  expanded  to  full  screen 
size  by  clicking  on  the  expand  icon  in  the  upper  right  of  the  table  of  contents  field.  The 
expanded  image  is  still  scrollable.  Clicking  on  any  point  in  the  table  of  contents  causes  the 
document  display  to  move  to  the  selected  point  in  the  text 

9.6.2  Main  Text  Window 

The  main  text  window  displays  the  text  on  the  current  page  of  the  maintenance  manual.  The 
field  is  scrollable  in  the  event  that  not  all  the  text  is  visible  at  one  time  however  this  will  rarely 
occur  because  the  import  tools  which  transform  the  text  into  hypermedia  form  divide  the  text  in 
the  paper  manual  into  multiple  pages  for  display  on  the  screen.  The  actual  page  number  of  the 
material  in  the  paper  document  is  displayed  but  several  pages  of  screen  display  may  equal  one 
paper  page.  This  format  was  selected  after  extensive  research  into  how  much  information 
should  be  displayed  on  a  computer  screen  at  one  time. 

It  should  be  noted  that  because  we  do  not  want  a  user  to  be  able  to  alter  any  of  the  primary 
document,  all  the  text  visible  in  the  main  window  is  locked  text  and  cannot  be  changed. 
Notes  can  be  taken,  and  supplemental  text  or  graphics  can  be  added  by  an  authorized  user  as 
will  be  described  later,  but  the  formal  document  cannot  be  modified.  In  Macintosh  software, 
locked  text  cannot  be  selected.  Since  many  of  the  features  of  the  Diagnosis  Apprentice  require 
selection  of  text  in  the  main  window  (locked  text),  we  had  to  circumvent  and/or  modify  several 
aspects  of  Supercard. 

9.6.3  Figures 

As  shown  in  figures  35,  36,  and  37,  figures  associated  with  the  text  on  a  given  page  is 
displayed  on  the  upper  right  of  the  screen.  The  figure  will  automatically  change  as  the  text 
changes  so  that  the  correct  figure  will  always  be  visible  on  the  screen.  The  figure  can  be 
expanded  to  full  screen  size  by  clicking  on  the  expand  icon.  A  small  part  of  the  icon  is  barely 
visible  on  the  upper  right  of  figure  35.  Clicking  on  the  icon  again  returns  the  figure  to  its  small 
size.  When  expanded,  forward  and  backward  arrows  are  also  visible  which  can  be  used  to 
"leaf'  through  the  figures,  either  forward  or  backward. 

9.6.4  Notebook 

The  user  can  make  notes  in  a  notebook  associated  with  any  specific  test.  The  notebook 
window  is  scrollable,  and  is  also  expandable  to  fill  the  entire  right  half  of  the  screen.  The 
expand  (and  contract)  icon  is  barely  visible  in  figure  37.  Arbitrary  notes  can  be  typed  into  the 
notebook,  or  they  can  be  copied  into  the  notebook  from  any  other  text.  The  steps  to  mark  and 
then  copy  text  are  similar  to  the  normal  way  to  mark  and  copy  text  in  any  of  the  Apple 
Macintosh  word  processing  packages.  Clicking  once  on  a  word  selects  the  word.  Clicking 
twice  on  a  word  selects  the  entire  sentence.  Clicking  on  any  word  and  then  holding  down  the 
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shift  key  and  clicking  on  any  other  word  selects  all  the  text  between  the  two  words.  The  edit 
icon  at  die  top  of  the  notebook  window  contains  the  usual  copy  and  paste  services. 

9.6.5  Glossary 

There  is  an  on-line  glossary  which  will  give  the  definition  of  any  selected  word  which  is 
contained  in  the  glossary.  The  glossary  is  shown  on  the  top  of  figure  36,  where  the  definition 
of  the  acronym  MGM  is  currendy  displayed  in  the  glossary  window.  Once  a  definition  is 
displayed,  clicking  on  the  page  icon  will  cause  the  text  where  that  term  was  first  used  in  the 
entire  document  to  be  displayed  in  the  main  text  window.  The  concept  is  that  the  place  where  a 
term  is  first  used  is  the  place  where  it  is  most  completely  defined.  Clicking  again  on  the  page 
icon  causes  a  box  to  be  drawn  around  that  first  occurrence  of  the  word  on  the  page  currently 
displayed  on  the  screen.  The  glossary  is  scrollable,  and  can  be  closed  by  selecting  the  close 
icon.  The  glossary  window  is  not  expandable. 

9.6.6  Speech 

A  speech  synthesizer  will  verbalize  any  selected  text  when  the  speech  icon  is  selected.  The  text 
is  selected  exactly  as  text  was  selected  to  be  copied  into  the  notebook.  This  was  described  in 
section  9.6.4  above.  Any  text  in  the  main  text  window,  in  the  glossary,  or  in  the  figure 
captions  can  be  selected. 

9.6.7  Import  Tools 

Some  of  the  tools  provided  for  importing  supplementary  material  are  shown  on  figure  37  and 
arc  described  below.  There  are  also  a  set  of  tools  for  importing  existing  maintenance  manuals, 
but  those  details  are  beyond  the  scop*,  of  this  report.  We  would  be  pleased  to  provide 
additional  details  on  request 

9.6.7.1  Linking  of  Video  Sequences  from  a  video  disk 

At  any  point  in  the  text,  a  section  from  a  video  disk  can  be  linked  into  the  text.  Figure  37 
shows  the  set  of  tools  which  can  be  used  for  importing  supplementary  materials,  as  described 
in  section  9.6.7.  Selecting  the  video  disk  player  controller  and  the  video  link  editor  menu  items 
causes  the  windows  shown  in  figure  38  to  be  displayed.  Using  these  fields,  the  video  disk  can 
be  controlled,  and  using  the  linking  tools,  the  correct  place  in  the  text  can  be  linked  to  that  point 
on  the  video  disk.  During  use,  if  there  is  a  supplemental  video  section  associated  with  a 
particular  section  of  text,  an  icon  will  appear  at  the  bottom  of  the  screen.  If  the  user  selects  this 
icon,  the  video  player  will  automatically  position  to  the  correct  point,  and  play  the  sequence  as 
defined  by  the  links.  The  video  link  editor  and  the  video  disk  controller  windows  can  be 
moved  anywhere  on  the  screen,  and  can  be  closed  by  clicking  on  the  close  box  in  their  upper 
left  comer. 

9.6.7.2  Add  Explanation,  Import  Pictures 

Supplemental  material  can  be  added  to  an  existing  manual  without  changing  the  basic  document 
which  has  been  approved  for  use.  Our  system  has  tools  for  linking  both  supplemental  graphics 
or  supplemental  text.  In  these  cases,  icons  will  appear  at  the  bottom  of  the  screen  to  indicate 
that  there  is  supplemental  material  present.  That  material  can  be  displayed  by  clicking  on  the 
appropriate  icon.  Graphics  can  be  imported  by  scanning  an  existing  picture,  or  a  video  camera 
can  be  used  to  capture  an  actual  image,  which  will  be  linked  into  the  document  exactly  as  it 
would  if  the  image  had  been  scanned. 

9.6.7.3  Add  Questions 
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One  of  our  goals  in  developing  the  automated  maintenance  manual  described  above  is  to  be  able 
to  use  the  system  in  a  computer-based  training  system.  As  shown  on  figure  37,  some  of  the 
tools  which  we  created  allow  questions  to  be  included  with  the  manual.  If  there  have  been 
questions  added,  a  "question"  icon  will  appear  at  the  bottom  of  the  screen.  Room  is  provided 
for  the  "student"  to  answer  the  question,  and  aids  are  also  provided  to  help  the  student  answer 
the  question.  Since  these  capabilities  are  not  directly  relevant  to  the  subject  work,  we  will  not 
go  into  detail  as  to  these  functions  and  services. 

9.6.8  Hierarchical  Figures 

Figures  39,  40,  and  41  show  the  types  of  links  that  have  been  implemented  between  figures 
and  the  instructions  related  to  those  figures,  and  between  figures  and  the  subparts  of  those 
figures.  Figure  39  shows  a  figure  and  a  list  of  subcomponents  of  that  figure.  When  one  of  the 
subcomponents  is  selected  with  the  mouse,  a  large  red  arrow  points  to  the  particular  subpart. 
Figure  40  shows  instructions  for  performing  a  repair  operation  on  the  displayed  part.  When 
the  specific  instruction  is  selected,  arrows  are  drawn  to  the  parts.  Then  selecting  the  parts 
identified  by  the  arrow  causes  expanded  views  of  the  parts  to  be  drawn  in  a  separate,  movable 
window.  Forward  and  backward  arrows  can  be  used  to  view  all  of  the  subcomponents  if  that 
is  desired. 

10.  Major  Example 

ARINC  has  provided  IAI  with  the  dependency  models  used  for  testability  analysis  and  for  on¬ 
line  diagnosis  of  the  A2  and  A3  shop  replacable  assemblies  for  the  high  voltage  power  supply 
from  the  AV-8B  heads-up  display.  The  A3  dependency  file  contains  33  tests  and  120 
components  and  supports  fault  isolation  to  42  groups  of  1  or  more  components.  The  A2 
dependency  file  contains  23  tests  and  64  components  and  supports  fault  isolation  to  32  groups 
of  1  or  more  components.  The  tool  for  which  the  dependency  model  was  prepared  was 
POINTER,  developed  and  marketed  by  ARINC. 

We  have  taken  the  dependency  model  provided  by  ARINC  and  converted  it  manually  to  the 
formal  data  model  detailed  in  section  8  of  this  final  report.  There  were  no  problems  associated 
with  the  conversion  although  it  was  not  the  most  conclusive  test  of  the  adequacy  of  the  neutral 
format  because  the  particular  dependency  models  (for  the  A2  and  A3  shop  replacable  units)  had 
no  conditional  dependencies  or  asymmetries. 

Then,  to  demonstrate  that  the  data  could  then  be  transferred  from  the  neutral  format  to  the 
internal  format  of  a  different  commercial  tool,  we  manually  converted  the  data  from  the  neutral 
format  into  the  format  of  STAT  by  DETEX  Systems,  Incorporated.  Again,  the  conversion  was 
simple  because  the  dependency  model  was  quite  simple  (even  though  it  was  for  an  actual 
component  in  systems  currently  in  use  by  the  Air  Force). 

The  models  are  quite  verbose  and  are  not  included  in  this  final  report  but  they  will  be  provided 
on  request.  Appendix  3  is  the  STAMP  input  data  for  the  simpler  of  the  two  power  supplies 
used  in  this  experiment  -  the  HVA2  High  Voltage  Power  Supply  A2  Model  for  the  AV-8B 
heads-up  display. 

11.  Outside  Support 

As  part  of  our  Phase  1  SBIR  contract,  we  have  spoken  to  many  users  and  vendors  of  tools  for 
testability  and  maintainability  analysis.  All  of  the  people  we  have  spoken  to  were  supportive  of 
our  work.  We  have  received  support  from: 
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Bradford  Smith,  Chairman  of  STEP  (International  part  of  PDES  and  an  important 
part  of  the  CALS  Program) 

Ralph  DePaul,  President  of  DETEX  Systems,  Incorporated 

Randy  Simpson,  Designed  and  Implementor  of  STAMP,  and  POINTER 

Robert  Rolfe  of  the  Institute  for  Defense  Analyses,  key  participant  in  ABET 

Leslie  Orlidge,  Chari  man  of  the  AI-ESTATE  Committee  of  SCC-20 

John  Bloodgood,  Technical  Advisory  Group  (TAG)  Chairman  of  TC  184/SC  1  - 
NC  of  Machines  and  SC  5  -  Systems  Integration  and  Communications. 
Acting  TAG  Chairman  of  TC  1 84/SC  2  -  Industrial  Robots:  Current 
Chairman  of  IEQTC  44  Electrical  Equipment  of  Industrial  Machines 


We  have  also  received  support  from  numerous  DOD  representatives  including 

Dr.  Bob  Hillman  of  Rome  Laboratories 

Christine  Fisher,  Office  of  the  Secretary  of  Defense  (P&L)  SS&T 

We  have  also  received  support  from  Narayan  Ramachandran  of  TYX  Corporation,  and 
Douglas  Van  der  Heide  of  Van  der  Heide,  Inc.,  TYX  Corporation  produces  a  tool  named 
PAWS.  DETEX  Systems,  Incorporated  and  TYX  Corporation  have  developed  an 
exchange  format  which  allows  the  output  of  STAT  (DETEX)  to  be  used  without  change  as 
the  input  to  PAWS  (TYX).  The  exchange  format  has  helped  both  companies,  and  is  an 
example  of  what  could  be  achieved  with  a  National  standard.  Van  der  Heide,  Incorporated 
produces  a  tool  called  TAD  (TRD  and  ATLAS  Development). 

No  one  we  have  talked  to  has  been  negative. 

We  made  a  20  minute  presentation  to  the  full  IEEE  SCC20  committee  at  its  plenary 
meeting,  and  submitted  a  formal  PAR  (Project  Authorization  Request).  Figure  42  shows 
the  cover  page  for  the  presentation,  and  figure  43  is  the  actual  PAR.  We  were  given 
provisional  approval  to  proceed  with  development  under  the  formal  sponsorship  of  IEEE 
SCC20  -  an  ANSI  approved  standards  writing  body.  There  were  over  150  people  at  the 
SCC20  meeting,  and  I  received  many  very  positive  comments.  I  had  made  50  copies  of  the 
presentation,  and  gave  them  out  only  when  I  was  asked  for  a  copy.  I  ran  out  of  copies  and 
more  had  to  be  copied  at  the  meeting. 
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MAJOR  DOD  PROGRAMS  RELATED  TO  WEAPON  SYSTEM 
TESTABILITY  AND  MAINTAINABILITY 

(From  1987  report  to  AMC  by  IAI  -  may  now  be  obsolete) 

Integrated  Diagnostics  Support  System  (IDSS) 

Modular  Automatic  Test  Equipment  (MATE) 

Reliability  and  Maintainability  Factors  in  Computer  Aided 
Design 

(RAMCAD) 

"SMART"  Bit  Techniques 

Tester  Independent  Support  Software  System  (TISSS) 

Test  Engineers  Assistant  (TEA) 

Computer  Aided  Design/  Built  In  Test  (CAD-BIT) 

Atlas  Test  Support  Environment  (ATSE) 

Avionics  Integrity  Program  (AVIP) 

Ada-Based  Environment  for  Test  (ABET) 


Table  1.  DOD  Testability  and  Maintainability 
Analysis  Tools  and  Programs 


PERFORMANCE  AIDS 


Smart  Maintenance  Trainer 

Integrated  Maintenance  Information  System  (IMIS) 

Computer-Based  Aid  for  Troubleshooting  (CBAT) 

Predictive  Aircraft  Maintenance  System  (PAMS) 

Intelligent  Maintenance  Training  System 

Versatile  Maintenance  Expert  System 

Consolidated  Automated  Support  System  (CASS) 

Electronic  Information  Delivery  System  (EIDS) 

Intermediate  Forward  Test  Equipment  (IFTE) 

Miniaturized  Electronic  Information  Delivery  System 
(MEIDS) 

Personal  Electronics  Aid  For  Maintenance  (PEAM) 
Integrated  Maintenance  Information  System  (IMIS) 


Table  2.  DOD  Maintenance  Technician  Performance  Aids 


FIELD  DATA 


T 

FAILURE  RATES 
TIME  TO  DIAGNOSE 
TIME  TO  REPAIR 
RETEST  OK  RATES 
OPERATOR  TRAINING  REQUIRED 
ENVIRONMENTAL  FACTORS 
SPARES  USAGE 


DESIGN  PRODUCTION  DIAGNOSIS  AND  LOGISTICS 

CHANGES  IMPROVEMENTS  REPAIR  SUPPORT 

IMPROVEMENTS  IMPROVEMENTS 


TRAINING 

IMPROVE¬ 

MENTS 


ACCURATE  AND  EFFECTIVE  USE  OF  EXPERIENTIAL  DATA 
REQUIRES  FORMAL  DEFINITIONS  OF  THE  DATA,  AND 
STANDARD  INTERCHANGE  FORMATS. 

THE  DATA  MUST  BE  COMPATIBLE  WITH  THE  TOOLS  THAT 
USE  THE  DATA 


Figure  1 .  Use  of  Field  Data 


CONCURRENT  ENGINEERING  REQUIRES  INFORMATION  TO  BE  SHARED 


TRAINING 

PERSONNE 


Technician  Skill  Levels 
Training  Requirements 
Training  Material 
Requirements 


Cost  of  Production 
Production  Problems 
Reliability  Problems 


PRODUCTION 

PERSONNEL 


LOGISTICS 

SUPPORT 

PERSONNEL 


Cost  of  Spares 
Number  of  Spares  Required 
Storage  Requirements 
Transportation  Requirements 


Testability  Analysis 
Expected  Cost  to  Repair 
Expected  Time  to  Repair 
Technicial  Training  Time 
Technicians  Required 
Test  Equipment  Required 


MAINTENANCE 

PERSONNEL 


FOR  CONCURRENT  ENGINEERING  TO  WORK,  DATA  MUST  BE  SHARABLE  OVER 
A  WIDE  RANGE  OF  TOOLS 

DESIGN  TOOLS 

TESTABILITY  AND  MAINTAINABILITY  RELATED  TOOLS 
LOGISTIC  SUPPORT  TOOLS 

PROCESS  PLANNING  AND  PROCESS  CONTROL  TOOLS 
DATA  EXCHANGE  STANDARDS  ARE  ESSENTIAL 


Figure  2.  Shared  Data 


ISO  OPEN  SYSTEM  INTERCONNECTION 
REFERENCE  MODEL 


USER  A 


USER  B 


APPLICATION 

APPLICATION 

PRESENTATION 

PRESENTATION 

SESSION 

SESSION 

TRANSPORT 

TRANSPORT 

NETWORK 

NETWORK 

LINK 

LINK 

PHYSICAL 

PHYSICAL 

i 


Figure  3.  OSI  Reference  Model 


Current  Emphasis 


“4.3  The  Test  Strategy  Standards 

Note:  The  standards  explicitly  associated  with  the  test  strategy  are  not 
implemented  in  the  current  issue  of  ABET." 
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Current  RAM  Tools 


SCC20  Test 
Procedure  Layer 


Symptom  Library  Layer  ** 


Fault  Tree  Layer 

SCC20  Test 

"  “  -  —  Strategy  Layer 

Ambiguity  Group  Layer 


Dependency  Model  Layer 


SCC20  Product 
Model  Layer 


**  The  Symptom  Library  Level  is  Under 
Consideration  -  No  work  has  been  done  to  define 
this  layer  within  the  SCC20  Open  Architecture 


Figure  7.  Proposed  Structure  Within 
Test  Strategy  Layer 
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Figure  8.  Robot  Hand-Eye 

Coordination  System 
System  Level  Diagram 


Robotic  Hand_eye  Coordination  System 
System  Level  Example 
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Test  Enter 

Time  to  Test 
Cost  to  Test 
Test  Reliability 
Technicians  required 
Equipment  Required 
Test  Group  Data 

For  Each  Part  Enter 

Time  to  Replace 
Cost  to  Replace 
Probability  of  Failure 
Inventory  Status 


Figure  9.  Dependency  Model  for  the  Robotic 
Hand-Eye  Coordination  System 
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STAT  I  Demo  Version  1.6.4 
Thu  Feb  07  19:13:51  1980 
SYSTEM  8 :  trypipel 

MODEL  2:  model2  CASE  1:  1 

FEEDBACK  LOOP  INDICATOR  REPORT 

SUMMARY  ANALYSIS 


Total  Number  of  Feedback  Loops 
Probability  of  Failure  within  a  Feedback  Loop 
%  of  All  Items  Involved  in  Feedback  Loop(s) 
Feedback  Loop  Complexity 


=  1 
=  0.51111111 

=  80.00 
=  0.8000 


Feedback  Loop  Complexity  Chart 


1.00 


FLC  =  0.8000 


0.75 


0.50 
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0.00 


xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 

xxxxxx 


Feedback  Loop 
Complexity 


Aggregate  Item  Characteristics  per  Feedback  Loop: 


Feedback 
Loop  ID# 

Number 
of  Items 

Cost  to 
Replace 

Time  to 

Replace 

Failure 

Probability 

1 

+  +  8 

++  5350.00 

++  211.00 

++  0.51111111 

TOTALS : 

8 

5350.00 

211.00 

AVERAGE : 

8.00 

5350.00 

211.00 

Figure  10.  Output  of  STAT 
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Thu  Feb  07  19:12:53  1980 
SYSTEM  8:  trypipel 

MODEL  2:  model2  CASE  1:  1 

FAULT  ISOLATION  INDICATOR  REPORT 
SUMMARY  ANALYSIS 


Statistics  to  Isolate  a  Primary  Failure: 

Number  of  Tests:  MINIMUM  =  3 

MAXIMUM  =  5 

AVERAGE  =  4.00 

Test  Cost:  MINIMUM  =  5.00 

MAXIMUM  =  9.00 

AVERAGE  =  7.29 

Test  Time:  MINIMUM  =  5.00  minutes 

MAXIMUM  =  9.00  minutes 

AVERAGE  =  7.29  minutes 

Number  of  Enclosures:  MINIMUM  =  1 

MAXIMUM  =  1 

AVERAGE  =  1.00 


Dynamic  Item  Involvement  Ratio  Statistics 

Without  Failure  Rates:  With  Failure  Rates: 

MINIMUM  =  0.25000000  MINIMUM  =  0.00555556 

MAXIMUM  =  0.25000000  MAXIMUM  =  0.11111111 


Figure  1 1 .  Output  of  STAT 
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Thu  Feb  07  19:12:54  1980 
SYSTEM  8:  trypipel 

MODEL  2:  model2  CASE  1:  1 

FAULT  ISOLATION  INDICATOR  REPORT 
DETAIL  ANALYSIS 
Diagnostic  Flow  Table 
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Figure  12. 


Optimal  Test  Flow  for  Example  2 
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BREAKPOINT  CANDIDATES  LISTING 


Feedback  Loop  1  of  1 


Breakpoint  Candidates 
Test  -Asp  Description 


T8  -1  composite  imaqe 

T9  -1  3-D  point- 

T7  -1  qrab_frame  siqnal 

T10  -1  trajectory- 

Tll  -1  smooth  path 

T13  -1  sync  signal 

T14  -1  command  to  robot 

T12  -1  robot .control _si gns 


of  AGs 

Mi  n 

AG  Size 
Max 

Avg 

6 

1 

4 

1.50 

6 

1 

4 

1.50 

6 

1 
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1.50 

G 
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1.50 

G 

1 

4 

1.50 

8* 

1 
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1 .  12* 
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2 
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0# 

1 

2* 
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END  OF  LISTING 


Figure  13.  Breakpoint  Candidates  for  Example  2 
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thu  Feb  07  11i47ilS  IfiO 
System  Si  trypipei 

MODEL  2i  model 2 
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FEEDBACK  LOOP  INDICATOR  REPORT 
SUMMARY  ANALYSIS 


Total  Number  of  Feedback  Loops 
Probability  of  Failure  within  a  Feedback  Loop 
X  of  All  Items  Involved  in  Feedback  Loop(s) 
Feedback  Loop  Complexity 


=  0.33333333 

=»  40.00 

=  0.4000 


— 

1 

1.00  I 

1 

1 

Feedback  Loop  Complexity  Chart 

1  1 

1  0.75  1 

l  l 

i  i 

s 

1 

0,50  ! 

1 

FLC  =  0.4000 
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! 

XXXXXX 

i 

XXXXXX 
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XXXXXX 
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XXXXXX 

1 

1 

XXXXXX 

I 

» 

XXXXXX 

1  1 

1  1 

XXXXXX 

1  i 

XXXXXX 

0.00  - 

Feedback  Loop 

9 

_ 

Compl  exi ty 

Aggregate  Item  Character i st i cs  per  Feedback  Loop: 


Feedbac  k 
Loop  ID# 


BtSaBSSBXSSSS 

TOTALS: 

AVERAGE: 


Number 
of  Items 


Cost  to 
Replace 


Time  t o 
Repl ac  e 


4 

4.00 


2450.00  ++ 

’2450700 

2450.00 


101.00 

Ioi7oo 
101. 00 


Failure 
Probabi 1 ity 

++  0.33333333 


END  OF  REPORT 


Figure  14. 

RESULTS  FROM  BREAKING  FEEDBACK  LOOP  AT  T7 
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Thu  Feb  07  19:12:53  1980 
SYSTEM  8:  trypipel 

MODEL  2:  mode 12  CASE  1:  1 

FAULT  ISOLATION  INDICATOR  REPORT 
SUMMARY  ANALYSIS 


Dynamic  Ambiguity  Group  Statistics: 

Total  Unique  Ambiguity  Group  Size(s):  2 

Total  Unique  Ambiguity  Group  (s):  4 

Total  Ambiguity  Group (s) :  4 


Ambiguity  Group 
Unique  Total 

Size  Qty  Qty 


Relative  Relative 

Isolation  Levels  Failure  Probability 
size  %  cum  %  size  %  cum  % 


75.00  75.00  53.33  53.33 

25.00  100.00  46.67  100.00 


Figure  15.  Results  from  Breaking  Loop  at  T7 
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Thu  Feb  07  19:56:33  1980 
SYSTEM  8:  trypipel 

MODEL  2 :  model2 

FAULT  ISOLATION  INDICATOR  REPORT 
SUMMARY  ANALYSIS 
I 

I  Dynamic  Ambiguity  Group  Statistics: 

I 
I 

I  Total  Unique  Ambiguity  Group  Size(s):  1 

I 

I  Total  Unique  Ambiguity  Group (s):  10 

I 

I  Total  Ambiguity  Group  (s):  10 

I 
I 

I  Ambiguity  Group  Relative  Relative 

I  Unique  Total  Isolation  Levels  Failure  Probability 

I  Size  Qty  Qty  size  %  cum  %  size  %  cum  % 


1  10  10  100.00  100.00  100.00  100.00 


Figure  16. 

RESULTS  FROM  BREAKING  FEEDBACK  LOOP  AT  T1  3 


S/N:  STI0106040001 000054 6 
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STAT  I  Demo  Version  1.6.4 
Thu  Feb  07  19:56:33  1980 
SYSTEM  8:  trypipel 

MODEL  2 :  model2 


FAULT  ISOLATION  INDICATOR  REPORT 
SUMMARY  ANALYSIS 


Statistics  to  Isolate  a  Primary  Failure: 


Number  of  Tests: 

MINIMUM 

= 

4 

MAXIMUM 

= 

6 

AVERAGE 

= 

4 . 92 

Test  Cost: 

MINIMUM 

— 

5.00 

MAXIMUM 

= 

11.00 

AVERAGE 

= 

8.62 

Test  Time: 

MINIMUM 

ssr 

5.00 

minutes 

MAXIMUM 

= 

11.00 

minutes 

AVERAGE 

= 

8.62 

minutes 

Number  of  Enclosures: 

MINIMUM 

- 

1 

MAXIMUM 

= 

1 

AVERAGE 

= 

1.00 

Dynamic  Item  Involvement  Ratio  Statistics 


Without  Failure  Rates: 

MINIMUM  =  0.10000000 

MAXIMUM  =  0.10000000 


With  Failure  Rates: 

MINIMUM  =  0.00222222 

MAXIMUM  =  0.04444444 


.  STAT  Outputs  for  Example  2  with  Loop  Broken  at  T1 3 


S  f 


Figure  1 7 


FAULT  ISOLATION  INDICATOR  REPORT 


DETAIL  ANALYSIS 
Diagnostic  Flow  Table 
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-1 
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1  4. 
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Replace 
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Replace 
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Replace 
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Goto 
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Replace 
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Figure  18 


Optimal  Fault  Tree  for  Example  2 
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Figure  19.  Interlaced/Non- Interlaced  Sync  Signal  Generation  Circuit 
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Wed  Feb  06  20:18:30  1980 
SYSTEM  1 :  test_system 

MODEL  2:  non-interlaced_sync_box  CASE  10:  base  case 

FAULT  ISOLATION  INDICATOR  REPORT 
SUMMARY  ANALYSIS 


Statistics  to  Isolate  a  Primary  Failure: 


Number  of  Tests: 

MINIMUM 

= 

2 

MAXIMUM 

= 

7 

AVERAGE 

= 

5.45 

Test  Cost : 

MINIMUM 

— 

2.00 

MAXIMUM 

= 

13.00 

AVERAGE 

= 

9.82 

Test  Time: 

MINIMUM 

= 

2.00 

minutes 

MAXIMUM 

= 

13.00 

minutes 

AVERAGE 

= 

9.82 

minutes 

Number  of  Enclosures: 

MINIMUM 

— 

1 

MAXIMUM 

= 

1 

AVERAGE 

= 

1.00 

Dynamic  Item  Involvement  Ratio  Statistics 


Without  Failure  Rates: 

MINIMUM  =  0.05263158 

MAXIMUM  =  0.05263158 


With  Failure  Rates: 

MINIMUM  =  0.00021265 

MAXIMUM  =  0.01063264 


Figure  20.  STAT  Output  for  Example  3 
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Wed  Feb  06  20:18:30  1980 
SYSTEM  1:  test_system 

MODEL  2:  non-interlaced_sync_box  CASE  10:  base  case 

FAULT  ISOLATION  INDICATOR  REPORT 
SUMMARY  ANALYSIS 


Dynamic  Ambiguity  Group  Statistics: 


Total  Unique  Ambiguity  Group  Size(s):  2 

Total  Unique  Ambiguity  Group (s) :  19 

Total  Ambiguity  Group (s):  19 


Ambiguity  Group 
Unique  Total 
Size  Qty  Qty 


Relative 
Isolation  Levels 
size  %  cum  % 


Relative 

Failure  Probability 
size  %  cum  % 


1  18 
2  1 


18  94.74  94.74  99.19  99.19 

1  5.26  100.00  0.81  100.00 


Figure  21 


STAT  Output  for  Example  3 


5TAT  I  Demo  Version  1.6.4 


S/Ns  ST I 01 0604000 10000546 


^led  Feb  06  20s  10s  28  1980 
SYSTEM  Is  test  system 

J10DEL  2s  non-i nter 1 aced_sync_box 


Page  0003 


ced_sync_box  CASE  10s  base  case 
FEEDBACK  LOOP  INDICATOR  REPORT 


SUMMARY  ANALYSIS 


Total  Number  of  Feedback  Loops 
Probability  of  Failure  within  a  Feedback  Loop 
%  of  All  Items  Involved  in  Feedback  Loop (. s ) 
Feedback  Loop  Complexity 


=  0.00808081 
=  10.00 
=  0. 1000 


Feedback  Loop  Complexity  Chart 


1.00 


0.75 


0.50 


0.25 


0.00 


FLC  =  0. 1000 

XXXXXX 

XXXXXX 


Feedback  Loop 
Compl exi ty 


Aggregate  Item  Character i sties  per  Feedback  Loops 


Feedbac  k 
Loop  ID# 


TOTALSs 

AVERAGE: 


Number 
of  Items 


Cost  to 
Repl ace 


Time  to 
Replace 


Fai lure 
Pr obabi 1 i ty 


2 

2.00 


2.00 

2.00 


4.00  ++  0.00808081 

'a~oo 

4.00 


END  OF  REPORT 


Figure  22.  STAT  Output  for  Example  3 
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DETAIL  ANALYSIS 
Diagnostic  Flow  Table 
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Figure  23.  Fault  Tree  for  Example  3. 
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Figure  23.  Continued 
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APPENDIX  1 


OUTPUT  FROM  STAT  DEPENDENCY-BASED  TESTABILITY 
TOOL  MARKETED  BY  DETEX  SYSTEMS,  INCORPORATED 


DATA  FROM  ROBOTIC  HAND-EYE  COORDINATION 
SYSTEM  -  HIGH  LEVEL  SYSTEM  BLOCK  DIAGRAM  LEVEL 


THE  ROBOTIC  HAND-EYE  COORDINATION  SYSTEM  WAS 
DEVELOPED  BY  IAI  FOR  THE  ARMY  ARMAMENT  RESEARCH, 
DEVELOPMENT,  AND  ENGINEERING  CENTER,  PICATINNY 

ARSENAL,  NJ 


System  i  B-0 
Model  i  2-0 


DEFINED  TESTS 
Page  1 


1. 


2. 


3. 


4. 


T 1  —  1 « 


Descr i  pt  i  on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 
Level  # 


IS? 


Selection  Status: 


T2-2: 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 
Level  # 


i 
3 
I 

• 
■ 

I 

Selection  Status: 


T3-1 : 


Description  : 
Cost  of  Test  : 
Time  to  Test  : 
Enclosure  #  : 
Level  #  l 
Type  i 
Selection  Status: 


T  4- 1 1 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 
Level  # 

>e 


Is?: 


: 
: 
: 
: 
: 
: 

Selection  Status: 
o  Dangling  Tests:  CO] 
o  Item  Aspect  Dependencies: 

o  Cause  Test  Dependencies: 

To  Item  Aspect  1 1-1:  Cl] 
Tl-1 


cameral  input 

0.00 

0.00  minutets) 
1 
1 

PROBE 

ALLOWED 


earner a2  i nput 

0.00 

0.00  minute(s) 
1 
1 

PROBE 

ALLOWED 


test  data  input 

0.00" 

0.00  minute(s) 

1 

1 

PROBE 

ALLOWED 


test  imagel 

2.00" 

2.00  minute(s) 
1 
1 

PROBE 

ALLOWED 


Cl  ] 


T5-1 : 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 
Level  # 

Type 

Selec  tion  Statu 


:  test  image2 

:  2.00" 

:  2.00  minuteCs) 
:  1 
:  1 

:  PROBE 
si  ALLOWED 


o  Dangling  Tests:  CO] 

o  Item  Aspect  Deoendenc i es :  Cl] 
12-1 


System  ;  8-0 
Model  i  2-0 


DEFINED  TESTS 
Page  2 


6. 


7. 


8. 


o  Cause  Test  Dependencies! 
To  Item  Aspect  1 2— 1  a  C13 
T2-1 


T2-1 1 

Description  i 

Cost  of  Test  i 

Time  to  Test  i 

Enclosure  #  i 

Level  #  i 

Selection  Status! 


T6-1: 

Description  i 

Co  st  o  f  Test  8 

Time  to  Test  t 

Enclosure  #  s 

Level  #  i 

Selection  Status: 

o  Dangling  Tests:  C03 

o  Item  Aspect  Dependencies: 
13-1 

o  Cause  Test  Dependencies: 

To  Item  Aspect  13-1:  Cl  3 
T3-1 


T7-1: 

Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Selection  Status 

o  Dangling  Tests:  C03 

o  I^em  Aspect  Dependencies: 
1 10-1 

o  Cause  Test  Dependencies: 
To  Item  Aspect  1 10-1 »  Cl  3 
T13-1 


camer«2  input 

0.00 

0.00  minuteCs) 
1 
1 

PROBE 

ALLOWED 


check  claibration 
4.00 

4.00  minuteCs) 

1 

1 

PROBE 

ALLOWED 


Cl  3 


qrab  frame  signal 
3.00" 

3.00  minuteCs) 

1 

1 

PROBE 

ALLOWED 


Cl  3 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 
Level  # 


:  sync  signal 

:  2.00" 

i  2.00  minuteCs) 
!  1 
t  1 


9 


T13-1 : 


DEFINED  TESTS 
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System 

Model 


10. 


11. 


l  8-0 
i  2-0 


Selection  Status 

o  Dangling  Testsi  CO] 

o  Item  Aspect  Dependencies: 
19-1 


:  PROBE 
:  ALLOWED 

Cl] 


o  Cause  Test  Dependencies: 
To  Item  Aspect  19-1:  Cl] 
T12-1 


TB-li 


Description  : 
Cost  of  Test  : 
Time  to  Test  : 
Enclosure  #  : 
Level  #  : 
Type  : 
Selection  Status: 


o  Dangling  Tests:  CO 3 


composite  image 

2.00  “ 

2.00  minuteCs) 

1 

1 

PROBE 

ALLOWED 


o  Item  Aspect  Dependencies:  Cl  3 


o  Cause  Test  Dependencies: 
To  Item  Aspect  14-1;  C33 
T4-1  T5-1 


T7-1 


T9-1 : 

Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Type 

Selection  Status 

o  Dangling  Tests:  C03 

o  Item  Aspect  Dependencies: 
13-1 


:  3-D  point 
i  3.00 

:  3.00  minuteCs) 

i  1 

:  1 

:  PROBE 
:  ALLOWED 


C13 


o  Cause  Test  Dependencies: 
To  Item  Aspect  15-1:  Cl] 
TB-1  ,7-6-1 


T10-1 1 


Description  : 
Cost  of  Test  i 
Time  to  Test  i 
Enclosure  #  i 
Level  #  : 
Type  i 


Selection  Status: 


tr a^ector y 

1.00  minuteCs) 
1 
1 

PROBE 

ALLOWED 


System  :  8-0 
Modal  t  2-0 


DEFINED  TESTS 
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©  Bitflilifif  T@it§i  C 0 3 
o  Item  Aspect  Dependencies:  Cl] 

o  Cause  Test  Dependencies: 

To  Item  Aspect  IS— 1  a  C13 
T9-1 


13. 


T 1 1  —  1 1 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 
Level  # 

Selection  Statu 


:  smooth  path 
:  1 . 00  “ 

:  1.00  minuteCs) 
:  1 
:  1 

:  PROBE 
s:  ALLOWED 


o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies:  Cl] 
17-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  17-1:  C13 
T10-1 


14. 


T12-1: 


Descr  i  pt  i  on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Selection  Status 


robot  contr ol  signs 
4.00 

4.00  minuteCs) 

1 

1 

PROBE 

ALLOWED 


o  Dangling  Tests:  C03 

o  Item  Aspect  Dependencies:  Cl] 
18-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  18-1:  C23 
Tll-1  T14-1 


IS. 


T14-1 : 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 


Selection  Status 
o  Dangling  Tests:  CO] 
o  Item  Aspect  Dependencies: 


command  to  robot 
5.00  "  - 

5.00  minuteCs) 

1 

i 

PROBE 

ALLOWED 


C2] 


System  i  8-0 
Model  j  2-0 
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Page  1 


Description  :  cameral 

Cost  to  Replace  s  1200.00 
Time  to  Replace  i  1.00  minuteCs) 
Failure  Rate  i  0.00010000 
Aspect  Descriptions! 

1.  <N0NE> 


Description  i  cameras 

Cost  to  Replace  i  1200.00 
Time  to  Replace  t  1.00  minuteCs) 
Failure  Rate  i  0.00010000 
Aspect  Descriptions: 

1.  <  NONE  > 

3.  13: 

Description  :  camera  calibration 

Cost  to  Replace  i  100.00“ 

Time  to  Replace  :  30.00  minuteCs) 
Failure  Rate  :  O.0O 100000 
Aspect  Descriptions: 

1.  <N0NE> 

4.  110: 

Description  :  control 

Cost  to  Replace  :  500.00 

Time  to  Replace  :  10.00  minute(s) 

Failure  Rate  l  0.00005000 

Aspect  Descriptions: 

1.  <N0NE> 


Description  :  image  frame_grabber 

Cost  to  Replace  :  1500.00 
Time  to  Replace  :  30.00  minuteCs) 
Failure  Rate  :  0.00010000 
Aspect  Descriptions: 

1.  <N0NE> 


Description  :  2D  to  3D_conv 

Cost  to  Replace  :  400.00 
Time  to  Replace  :  20.00  minuteCs) 
Failure  Rate  :  0.00010000 
Aspect  Descriptions: 

1.  <  NONE  > 

7.  16: 

Description  :  traj  predictor 

Cost  to  Replace  :  500.00 
Time  to  Replace  :  30.00  minuteCs) 
Failure  Rate  :  O.00O 10000 
Aspect  Descriptions: 

1.  <N0NE> 

8.  17: 

Description  :  smoothing  board 

Cost  to  Replace  :  500.00 
Time  to  Replace  :  30.00  minuteCs) 
Failure  Rate  :  0.00010000 
Aspect  Descriptions: 

1.  <N0NE> 


System  i  B-0 
Model  :  2-0 


ITEM  LIST 
Page  2 


9.  18: 


10.  19: 


Description  : 

Cost  to  Replace  : 
Time  to  Replace  : 
Failure  Rate  : 
Aspect  Description 
1.  <  NONE  > 


robot  control 
500.0(5 

30.00  minute(s) 
0.00010000 
s: 


Description  :  robot  control  port 

Cost  to  Replace  :  250.0(5 
Time  to  Replace  :  60.00  minute(s) 
Failure  Rate  :  0.00050000 
Aspect  Description*! 

1.  <N0NE> 


Page  0009 


Thu  Feb  07  19:12:54  1980 
SYSTEM  8:  trypipel 

MODEL  2:  model2  CASE  1:  1 

FAULT  ISOLATION  INDICATOR  REPORT 
DETAIL  ANALYSIS 
Diagnostic  Flow  Diagram 


1-T15  -1 

1 

1 

robot_output 

|  NO  FAULTS  ENCOUNTERED 

1 

I 

1 

weighting  :+0. 00000000 

G 

1 

(cumulative  totals 

1 

1 

— 

|  tests:  1 

1 

time  so  far:  0.00 

i  test  cost: 

1.00 

1 

cost  to  go  :  4159.00 

I  test  time: 

1.00 

1 

time  to  go  :  219.00 

I  enclosures:  1 

1 

1 

B  1 

1-T6  -1 

check_claibration 

weighting  :+0. 00000000 

G 

time  so  far:  1.00 

to  page 

cost  to  go  :  4158.00 

0010 

time  to  go  :  218.00 

1-T5 

-1 

B  1 

1-T3  -1 

1  ******  fault  ****** 

1 

test_data_input 

1 

1 

I Sus  AG  Ref#:  1 

| 

1 

1 

weighting  :+0. 00000000 

G 

1 

(cumulative  totals 

1 

1 

— 

|  tests:  3 

1 

time  so  far:  5.00 

j  test  cost: 

5.00 

1 

cost  to  go  :  100.00 

I  test  time: 

5.00 

1 

time  to  go  :  30.00 

|  enclosures:  1 

1 

1 

B  1 

******  FAULT  ****** 

Input  :  1-T3  -1 

cumulative  totals 

tests:  3 

test  cost:  5.00 

test  time:  5.00 

enclosures:  1 

Page  0010 


Thu  Feb  07  19:12:54  1980 
SYSTEM  8:  trypipel 

MODEL  2 :  mode 12  CASE  1 :  1 

FAULT  ISOLATION  INDICATOR  REPORT 
DETAIL  ANALYSIS 
Diagnostic  Flow  Diagram 


G 


from  page 
0009 
1-T6 
-1 


1-T5  -1 

test_image2 


weighting  :+0. 00000000 

time  so  far:  5.00 
cost  to  go  :  4154.00 
time  to  go  :  214.00 


_ B  I 

1-T2  -1 

camera2_input 


weighting  :+0. 00000000 


time  so  far:  7.00 
cost  to  go  :  1200.00 
time  to  go  :  1.00 


_ B  I _ 

******  FAULT  ****** 

Input  :  1-T2  -1 

cumulative  totals 
tests:  4 

test  cost:  7.00 

test  time:  7.00 

enclosures:  1 


I  ******  fault  ****** 

I 

I Sus  AG  Ref#:  2 

I 

G  [cumulative  totals 
—  I  tests:  4 

I  test  Cotf.  7.00 

I  test  time:  7.00 

I  enclosures:  1 


to  page 
0011 
1-T4 
-1 
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Thu  Feb  07  19:12:55  1980 
SYSTEM  8:  trypipel 

MODEL  2:  model2  CASE  1:  1 

FAULT  ISOLATION  INDICATOR  REPORT 
DETAIL  ANALYSIS 
Diagnostic  Flow  Diagram 


G 


from  page 
0010 
1-T5 
-1 


1-T4  -1 

test_imagel 


weighting 

time  so  far 
cost  to  go 
time  to  go 


+0.00000000 


7.00 

4152.00 

212.00 


_ B  I 

1-T1  -1 

cameral_input 


weighting  :+0. 00000000 

time  so  far:  9.00 
cost  to  go  :  1200.00 
time  to  go  :  1.00 


_ B  | _ 

******  FAULT  ****** 

Input  :  1-T1  -1 

cumulative  totals 
tests:  5 

test  cost:  9.00 

test  time:  9.00 

enclosures:  1 


G 


G 


******  FAULT  ****** 

Sus  AG  Ref#:  4 

cumulative  totals 
tests:  4 

test  cost:  9.00 

test  time:  9.00 

enclosures:  1 


******  FAULT  ****** 

Sus  AG  Ref# :  3 

cumulative  totals 
tests:  5 

test  cost:  9.00 

test  time:  9.00 

enclosures:  1 


* 


a 

I 


APPENDIX  2 


OUTPUT  FROM  STAT  DEPENDENCY-BASED  TESTABILITY 
TOOL  MARKETED  BY  DETEX  SYSTEMS,  INCORPORATED 


DATA  FROM  INTERLACED/NON-INTERLACED  SYNC 
SIGNAL  GENERATION  DETAILED  CIRCUIT  DIAGRAM 


THE  INTERLACED/NON-INTERLACED  SYNC  SIGNAL  GENERATION 
CIRCUIT  WAS  PRODUCED  BY  IAI  FOR  THE  ARMY  ARMAMENT 
RESEARCH,  DEVELOPMENT,  AND  ENGINEERING  CENTER, 
PICATINNY  ARSENAL,  NJ. 


i  1=£ 

Model  t  2-0 


DEFINED  TESTS 
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1.  Tl-i i 


Description 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Type 

Selection  Status 


VSYNC  input 
1.00 

1.00  minute*. s.) 
1 
1 

PROBE 

ALLOWED 


2. 


T2-1 1 


Description 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 


ttr: 


t 

! 
■ 

t 
I 
I 

ction  St  at us i 


digitized  VSYNC 

1.00 

1.00  minuteCs) 

1 

1 

PROBE 

ALLOWED 


©  Dangling  Testsi  C 0 3 


o  Item  Aspect  Dependencies:  CIO 


o  Cause  Test  Dependencies: 
To  Item  Aspect  Il-li  C1D 
Tl-1 


3. 


T3-1 : 


Descr i pt i on 
Cost  of  i est 
Time  to  Test 
Enclosure  # 
Level  # 


Si? 


e 

ect i on 


Status 


:  VNORM  inverse 
:  1 . 00 

:  1.00  minute(s) 

:  1 
:  1 

:  PROBE 
:  ALLOWED 


o  Dangling  Tests:  COD 

o  Item  Aspect  Dependencies:  C1D 
12-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  12-1:  C1D 
T2- 1 


4. 


T7- 1 : 


Description  : 
Cost  of  Test  : 
Time  to  Test  : 
Enclosure  #  i 
Level  #  : 
Type  : 
Selection  Status: 


4  us  pulse  @  VSYNC 
4.00 

4.00  minute(s) 

1 

1 

PROBE 

ALLOWED 


o  Dangling  Tests:  COD 

o  Item  Aspect  Dependencies:  C1D 
13-1 


By«t»m  i  1-0 
Model  :  2-0 


DEFINED  TESTS 
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o  Cause  Test  Dependencies: 
To  Item  Aspect  13-1:  Cl] 
T3-1 


T4-1 : 


Descr i  pt  i  on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Sefection  Status 


o  Dangling  Tests:  C03 
o  Item  Aspect  Dependencies: 


o  Cause  Test  Dependencies: 
To  Item  Aspect 


6. 


T5-1 : 

Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Sefection  Status 

o  Dangling  Tests:  C03 

o  Item  Aspect  Dependencies: 
15-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  15-1:  C13 
T4-1 


7.  T6- 1 : 

Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Sefection  Status 

o  Dangling  Tests:  C03 

o  Item  Aspect  Dependencies: 
16-1 

o  Cause  Test  Dependencies: 
To  Item  Aspect  16-1:  Cl  3 


HSYNC  input 

1.00 

1.00  minute(s) 
1 
1 

PROBE 

ALLOWED 


diqitived  HSYNC 
1 . 00 

1.00  minute(.s.i 
1 
1 

PROBE 

ALLOWED 


Cl  3 


HNOFlM  inverse 
1 . 00 

1.00  minute(s) 
1 
1 

PROBE 

ALLOWED 


C  1  3 


System  i  1-0 
Model  j  2-0 


DEFINED  TESTS 
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T5-1 


a. 


T8-1 : 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Type  : 

Selection  Status! 


ODD  inverse 
4.00 

4.00  minute( 
1 
1 

PROBE 

ALLOWED 


pul  se 
s) 


o  Dangling  Tests:  COD 


o  Item  Aspect  Dependencies;  CiD 
14-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  14-1:  C2D 
T7-1  T6-1 


9. 


T9-1 : 

Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

li?  ection  Status 
o  Dangling  Tests:  COD 
o  It^m  Aspect  Dependencies: 


<  NONE  > 

0 .  00 

0.00  minute(s) 
1 
1 

PROBE 

ALLOWED 


CID 


o  Cause  Test  Dependencies: 
To  Item  Aspect  CID 


10. 


T 1 0- 1 : 


Descr  i  pt  i  on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Type 

Selection  Status 


x 100  counter  out 
1 . 00 

1.00  minute(s) 

1 

1 

PROBE 

ALLOWED 


o  Dangling  Tests:  COD 

o  Item  Aspect  Dependencies:  CID 
18-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  18-1:  C2D 
T8- 1  T13-1 


System  t  1-0 
Model  t  2-0 


DEFINED  TESTS 
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11.  T13-1 ! 

Description  : 

Cost  of  Test  • 

Time  to  Test  : 

Enclosure  #  : 

Level  #  : 

Type  s 

Selection  Status: 

o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies: 
19-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  19-1:  C2] 
T8-1  T14-1 


T 1 1  —  1  * 

Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Selection  Status 

o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies: 
19-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  19-1:  C2] 

T8-1  T14-1 


13.  T14-1 : 

Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Selection  Status 

o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies: 
1 10-1 

o  Cause  Test  Dependencies: 
To  Item  Aspect  1 10-1:  C23 
T8- 1  T 1 5-1 


14.  T12-1 : 


Description  : 


xlOO  ripple  in 
1 . 00 

1.00  minute(s) 
1 
1 

PROBE 

ALLOWED 


Cl] 


xiO  counter  out 

1.00 

1 . 00  minuteCs) 

1 

1 

PROBE 

ALLOWED 


Cl  3 


x  10  tipple  in 
1 . 00 

1.00  minuteCs.) 
1 
1 

PROBE 

ALLOWED 


Cl  3 


xl  counter  out 


iystem  i  1=0  DEFINED  TESTS 

Model  :  2-0  Page  5 


13. 


16. 


o 

o 


Cost  of  Test  : 

Time  to  Test  i 

Enclosure  #  : 

Level  #  : 

Type  s 

Selection  Status: 

Dangling  Tests:  CO] 

Item  Aspect  Dependencies: 

1 10-1 


1.00 

1.00  minute(s) 
1 
1 

PROBE 

ALLOWED 


Cl  ] 


o  Cause  Test  Dependencies: 
To  Item  Aspect  1 10-1:  C2] 
T8-1  T15-1 


T13-1 : 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Selection  Status 


xl  counter  out 
1 . 00 

1.00  minute(s) 
1 
1 

PROBE 

ALLOWED 


o  Dangling  Tests:  CO] 


o  Item  Aspect  Dependencies:  Cl] 
17-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  17-1:  Cl] 
T6- 1 


T1S-1 : 

Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Selection  Status 

o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies: 
1 1 1  - 1 


count  262  pulse 
4 . 00 

4.00  minute(s) 

1 

1 

PROBE 

ALLOWED 


Cl  ] 


out 


o  Cause  Test  Dependencies: 

To  Item  Aspect  1 1 1  —  1 1  C 3 3 

T10-1  Tll-1  T12-1 


Descript i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 


count  262  pulse 
4. 00 

4.00  minute Cs) 

1 


17 


T17-1 


System 

Model 


18. 


19. 


j  1-0  DEFINED  TESTS 

:  2-0  Page  £ 


Level  #  :  1 

Type  s  PROBE 

Selection  Status:  ALLOWED 

o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies:  Cl] 

1 12-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  112-1:  Cl] 
T16-1 


T18-1 : 

Descr i pt  i  on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Se?ection  Status 

o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies: 
113-1 


count  9  HSYNC  pulse 

2.00 

2.00  minuteCs) 

1 

1 

PROBE 

ALLOWED 


Cl] 


o  Cause  Test  Dependencies: 
To  Item  Aspect  113-1:  Cl] 
T17-1 


T19-1: 

Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Selection  Status 

o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies: 
114-1 


VFAKE  inverse 
1 . 00 

1.00  minutef. s.) 

1 

1 

PROBE 

ALLOWED 


Cl  ] 


o  Cause  Test  Dependencies: 
To  Item  Aspect  114-1:  C2] 

T18-1  T17-1 


T20-1 : 

VFAKE  $<  non-intrl 
1 . 00 

1.00  minute(s) 

1 
1 

PROBE 
ALLOWED 


Description  : 
Cost  of  Test  : 
Time  to  Test  : 
Enclosure  #  : 
Level  #  : 
Type  : 
Selection  Status: 


System 

Modal 


21 . 


22. 


23. 


I  i“©  DEFINED  TEST8 

i  2-0  Page  7 


o  Dangling  Tastai  COD 
o  Item^Aspect  Dependencies:  C 1 D 


o  Cause  Test  Dependencies: 
To  Item  Aspect  116-1:  C23 
T19-1  T25-1 


T25-1 : 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Selection  Status 


non-intr  mode 
1 . 00 

1.00  minuteCs) 
1 
1 

PROBE 

ALLOWED 


o  Dangling  Tests:  C03 


o  Item  Aspect  Dependencies:  Cl  3 
118-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  118-1:  C23 
T21-1  T23-1 


T21-1: 

Descr i pt i on 
Cost  o f  T est 
Time  to  Test 
Enclosure  # 

Level  # 

Selection  Status 

o  Dangling  Tests:  C03 

o  Item  Aspect  Dependencies: 
115-1 


VN0RM  &  interl 
1 . 00 

1.00  minuteCs) 
1 
1 

PROBE 

ALLOWED 


C13 


o  Cause  Test  Dependencies: 
To  Item  Aspect  115-1:  C23 
T3-1  T24-1 


T24-1 : 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 

Level  # 

Type  : 

Selection  Status: 


interlace  mode 

1.00 

1.00  minuteCs) 
1 
1 

PROBE 

ALLOWED 


o  Dangling  Tests:  C03 


a  n 


System  :  1-0 
Model  :  2-0 


DEFINED  TESTS 
Page  8 


o  Item  Aspect  Dependencies:  Cl] 
118-1 

o  Cause  Test  Dependencies: 

To  Item  Aspect  118-1:  C2] 

T21-1  T23-1 


24.  T22-1: 


Description  :  select  mode  input 

Cost  of  Test  :  1 . 00 

Time  to  Test  :  1.00  minute(s) 

Enclosure  #  :  1 

Level  #  :  1 

Type  ?  PROBE 

Selection  Status:  ALLOWED 


T23-1: 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 
Enclosure  # 
Level  # 


Sefect i on 


Status 


ODD  inv  &  mode  sel 
1 . 00 

1.00  minuteCs) 

1 

1 

PROBE 

ALLOWED 


o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies:  Cl] 
119-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  119-1:  C2] 
T8-1  T22-1 


Description  :  VSYNC  input 

Cost  of  Test  :  1.00 

Time  to  Test  :  1.00  minutets) 

Enclosure  #  i  1 

Level  #  :  1 

Type  :  PROBE 

Selection  Status:  ALLOWED 

o  Dangling  Tests:  CO] 

o  Item  Aspect  Dependencies:  Cl] 

1 17-1 

o  Cause  Test  Dependencies: 

To  Item  Aspect  117-1:  C2] 

T21-1  T20-1 


27 


T27-1 


Descr i pt i on 
Cost  of  Test 
Time  to  Test 


HNEW  inverse  out 

1.00 

1.00  minutet's) 


System  :  8-0 
Model  «  2-0 


DEFIN 

Page 


1 10-1  1 1-1 

o  Cause  Test  Dependencies; 
To  Item  Aspect  1 10-1:  C13 
T13-1 


:  robot  output 

:  1.00" 

l  1.00  minuteCs) 
:  1 
:  1 

•  PROBE 
Selection  Status:  ALLOWED 

o  Dangling  Tests:  C03 

o  Item  Aspect  Dependencies:  CIO 
19-1 


16. 


T15-1 : 


Descr i pt i on 
Cost  o  f  Test 
Time  to  Test 
Enclosure  # 
Level  # 

Type 


o  Cause  Test  Dependencies: 
To  Item  Aspect  19-1:  CIO 
T12-1 


urn 


System  i  1-0 
Model  :  2-0 


DEFINED  TESTS 
Page  3 


Enc 1 osure 
Level  # 
Type 

Sel ect i on 


#  t  1 

:  1 

!  PROBE 

Status!  ALLOWED 


o  Dangling  Tests:  COD 

o  Item  Aspect  Dependencies:  C23 
120-1 


o  Cause  Test  Dependencies: 
To  Item  Aspect  120-1:  C1D 
T6-1 


Description  :  <N0NE> 

Cost  of  Test  :  0.00 

Time  to  Test  :  0.00  minute(s) 

Enclosure  #  :  1 

Level  #  :  l 

Type  :  PROBE 

Selection  Status:  ALLOWED 


System  i  1-0 
Model  :  2-0 


ITEM  LIST 
Page  1 


1 .  II: 


12: 


3.  13: 


4. 


15: 


16: 


6.  14: 


7.  17: 


8.  18: 


Description  :  VSYNC  input  op  amp 

Cost  to  Replace  :  2.00 

Time  to  Replace  :  1000.00  minuteCs) 

Failure  Rate  :  0.00010000 

Aspect  Descriptions: 

1.  <N0NE> 


Description  :  inverter 

Cost  to  Replace  :  1.00 

Time  to  Replace  :  10.00  minuteCs) 

Failure  Rate  :  0.00002000 

Aspect  Descriptions: 

1.  <N0NE> 


Description  :  4  urn  one  shot 

Cost  to  Replace  :  2.00 
Time  to  Replace  :  10.00  minuteCs) 
Failure  Rate  :  0.66005000 
Aspect  Descr i pt i ons: 

1.  <  NONE  > 


Description  :  HSYNC  op  amp 

Cost  to  Replace  :  2.00 
Time  to  Replace  :  10.00  minuteCs) 
Failure  Rate  :  0.00010000 
Aspect  Descriptions: 

1.  <N0NE> 


Descr i pt i on 
Cost  to  Replace 
Time  to  Replace 
Fail ure  Rate  _  .  . 

Aspect  Descriptions: 
1.  <  NONE  > 


HSYNU  inverter 
1 . 00 

2.00  minuteCs) 
0 . 00002000 


Description  :  2  input  or  qate 

Cost  to  Replace  :  1 . 00 

Time  to  Replace  :  2.00  minuteCs) 
Failure  Rate  :  0.00002000 
Aspect  Descriptions: 

1.  <N0NE> 


Description  :  inverter 

Cost  to  Replace  :  1.00 

Time  to  Replace  :  2.00  minuteCs) 
Failure  Rate  :  0.00002000 


Aspect  Descriptions: 
1.  <N0NE> 


Description  :  xlO  counter 

Cost  to  Replace  :  3.00 
Time  to  Replace  :  2.00  minuteCs) 
Failure  Rate  :  0.00002000 
Aspect  Descriptions: 

1.  <  NONE  > 


tC  ( 


System  s  1-0 
Model  i  2-0 


ITEM  LIST 


Page  2 


9.  I9i 


10.  II 0 : 


11.  Ills 


12. 


112 


1 1: 


14.  114: 


15.  116: 


16.  115: 


Description  i  xlO  counter 

Cost  to  Replace  :  2.00 
Time  tc  Replace  :  2.00  minuteCs) 
Failure  Rate  :  0.00002000 
Aspect  Descriptions: 

1.  <  NONE  > 


Descr i pt i on 
Cost  to  Replace 
Time  to  Replace 
Failure  Rate 
Aspect  Descriptions: 
1.  <N0NE> 


xlO  counter 
2 . 00 

2.00  minute(s) 

0. 00002000 


Description  :  3  input  and  qate 

Cost  to  Replace  :  1 . 00 

Time  to  Replace  :  2.00  minuteCs) 
Failure  Rate  :  0.00001000 
Aspect  Descriptions: 

1.  <N0NE> 


Description  :  4  us  one  shot 

Cost  to  Replace  :  4.00 
Time  to  Replace  :  3.00  minuteCs) 
Fa i 1 ur  e  Rat  e  :  0 . 00005000 

Aspect  Descriptions: 

1.  <N0NE> 


Description  :  xlO  counter 

Cost  to  Replace  :  2.00 
Time  to  Replace  :  2.00  minuteCs) 
Failure  Rate  :  0.00002000 
Aspect  Descriptions: 

1.  <  NONE  > 


Description  :  flip  flop 

Cost  to  Replace  :  1.00 

Time  to  Replace  :  2.00  minuteCs) 
Failure  Rate  :  0.0'"'001000 
Aspect  Descriptions: 

1.  <  NONE  > 


Description  :  2  input  or  gate 

Cost  to  Replace  :  1.00 

Time  to  Replace  :  2.00  minuteCs) 
Failure  Rate  :  0.00000500 
Aspect  Descriptions: 

1.  <N0NE> 


Descr i pt i on 
Cost  to  Replace 
Time  to  Replace 
Failure  Rate 


Aspect  Descriptions: 


2  input  or  qate 
1 . 00 

2.00  minuteCs) 

0. 00000200 


/  e  X 


System  :  1-0 
Model  :  2-0 


ITEM 

Page 


1.  <N0NE> 


17.  119: 


18.  118: 


19.  117: 


io . 


1 20 : 


Description  :  2  input  and  qate 

Cost  to  Replace  :  1 . 00 

Time  to  Replace  :  2.00  minute(s) 
Failure  Rate  i  0.00000200 
Aspect  Descriptions: 

1.  <  NONE  > 


Description  :  flip  flop 

Cost  to  Replace  :  1.00 

Time  to  Replace  :  2.00  minutefs) 
Failure  Rate  :  0.00000200 
Aspect  Descriptions: 

1.  <  NONE  > 


Descr i pt i on 
Cost  to  Replace 
T i  me  t  o  Rep  1  a'  e 
Failure  Rate 
Aspect  Descriptions: 
1.  < NONE  > 


2  input  and  qate 
1 . 00 

2.00  minute(s) 

0 . 00000200 


Description  :  2  input  and  qate 

Cost  to  Replace  :  1.00 

Time  to  Replace  :  2.00  minuteCs) 
Failure  Rate  :  0.00000200 
Aspect  Descriptions: 

1.  <N0NE> 


w  r 


FAULT  ISOLATION  INDICATOR  REPORT 
DETAIL  ANALYSIS  Diagnostic  Flow  Diagram 


G 


to  page 
0019 
1-T27 
-1 


G 


to  page 
0014 
1-T16 
-1 


G 


to  page 
0013 
1-T23 
-1 


G 


to  page 
0011 
1-T6 
-1 


G 


/  ( 


******  fault  ****** 

Sus  AG  Ref#:  3 

cumulative  totals 
tests:  5 

test  cost:  11.00 

test  time :  11.00 

enclosures:  1 


1-T26  -1 

VSYNC  input 


weighting  :+0. 00000000 

time  so  far:  0.00 

cost  to  go  :  17.00 

time  to  go  :  23.00 

-  B! 

1-T25  -1 

non-intr  mode 


weighting  :+0. 00000000 

time  so  far :  1.00 

cost  to  go  :  16.00 

time  to  go  :  22.00 

.  B I  _ 

1-T8  -1 

ODD  inverse  pulse 


weighting  :+0. 00000000 

time  so  far:  2.00 

cost  to  go  :  13.00 

time  to  go  :  21.00 

B  I 

1 -T7  -1 

4  us  pulse  @  VSYNC 


weighting  :+0. 00000000 

time  so  far:  6.00 

cost  to  go  :  9.00 

time  to  go  :  17.00 

B  I 

1-T3  -1 

VNORJM  inverse 


weighting  :+0. 00000000 

time  so  far:  10.00 
cost  to  go  :  5.00 
time  to  go  :  12.00 


B  | 

to  page  0010  I 


1-T0002-1 


FAULT  ISOLATION  INDICATOR  REPORT 


DETAIL  ANALYSIS 
Diagnostic  Flow  Diagram 


from  page  I 

1-T3 

0009  | 

-1 

B  1 

1-T2  -1 

digitized  VSYNC 

weighting  :+0. 

00000000 

time  so  far: 

11.00 

cost  to  go  : 

4.00 

time  to  go  : 

11.00 

B| 

1-T1  -1 

VSYNC  input 

weighting  :+0. 

00000000 

time  so  far: 

12.00 

cost  to  go  : 

3.00 

time  to  go  : 

6.00 

B  1  _ 

******  fault 

****** 

Input  :  1-T1  -1 

cumulative  totals 

tests : 

7 

test  cost: 

13.00 

test  time: 

13.00 

enclosures : 

1 

I  ******  FAULT  ****** 

I 

I Sus  AG  Ref#:  2 

I 

G  | cumulative  totals 
tests:  6 

test  cost:  12.00 

test  time:  12.00 

enclosures:  1 


******  FAULT  ****** 

Sus  AG  Ref#:  1 

cumulative  totals 
tests:  7 

test  cost:  13.00 

test  time:  13.00 

enclosures:  1 


FAULT  ISOLATION  INDICATOR  REPORT 


DETAIL  ANALYSIS 
Diagnostic  Flow  Diagram 


1  1-T6  -1 

IHNORM  inverse 

1 

G 

1 

1  weighting  :+0. 

00000000 

from  page 

1 

Itime  so  far: 

10.00 

0009 

1  cost  to  go  : 

5.00 

1-T7 

Itime  to  go  : 

13.00 

-1 

1 

B  1 

I  1-T5  -1 

Idigitived  HSYNC 
1 

1 

I  weighting  :+0. 

1 

00000000 

1 

Itime  so  far: 

11.00 

1  cost  to  go  : 

4.00 

Itime  to  go  : 

1 

12.00 

B  | 

to  page  0012  I  1-T0004-1 


******  FAULT  ****** 

Sus  AG  Ref#:  6 

cumulative  totals 
tests:  5 

test  cost:  11.00 

test  time:  11.00 

enclosures:  1 


******  fault  ****** 

Sus  AG  Ref#:  5 

cumulative  totals 
tests:  6 

test  cost:  12.00 

test  time:  12.00 

enclosures:  1 


I 


C(0 


FAULT  ISOLATION  INDICATOR  REPORT 


DETAIL  ANALYSIS 


Diagnostic 

from  page  I  1-T5 

0011  |  -1 

_ B  | _ 

1-T4  -1  | 

HSYNC  input  I 


weighting  :+0. 00000000 


time  so  far:  12.00 
cost  to  go  :  3.00 
time  to  go  :  11.00 


_ B  | _ 

******  FAULT  ****** 

Input  :  1-T4  -1 

cumulative  totals 
tests:  7 

test  cost:  13.00 

test  time:  13.00 

enclosures:  1 


Flow  Diagram 


I  ******  fault  ****** 

I 

|Sus  AG  Ref#:  4 

I 

G  (cumulative  totals 
— (  tests:  7 

j  test  cost:  13.00 

I  test  time:  13.00 

I  enclosures:  1 


FAULT  ISOLATION  INDICATOR  REPORT 


DETAIL  ANALYSIS 
Diagnostic  Flow  Diagram 


G 


from  page 
0009 
1-T8 
-1 


1-T23  -1 

ODD  inv  &  mode  sel 


weighting  :+0. 00000000 

time  so  far:  6.00 
cost  to  go  :  3.00 
time  to  go  :  5.00 


_ B  | _ 

1-T22  -1 

select  mode  input 


(weighting  :+0, 00000000 


time  so  far:  7.00 
cost  to  go  :  2.00 
time  to  go  :  3.00 


_ B  I _ 

******  FAULT  ****** 

Input  :  1-T22  -1 

cumulative  totals 
tests:  5 

test  cost:  8.00 

test  time:  8.00 

enclosures:  1 


I  ******  fault  ****** 

I 

i Sus  AG  Ref#:  8 

I 

G  (cumulative  totals 
— |  tests:  4 

I  test  cost:  7.00 

|  test  time:  7.00 

I  enclosures:  1 


I  ******  fault  ****** 

I 

| Sus  AG  Ref#:  7 

I 

G  (cumulative  totals 
—  I  tests:  5 

|  test  cost:  8.00 

)  test  time:  8.00 

I  enclosures:  1 


I 


00 


FAULT  ISOLATION  INDICATOR  REPORT 


DETAIL  ANALYSIS 
Diagnostic  Flow  Diagram 


G 


from  page 
0009 
1-T25 
-1 


1-T16  -1 

count  262  pulse  out 

weighting  :+0. 00000000 

G 

time  so  far:  2.00 

to  page 

cost  to  go  :  15.00 

0017 

time  to  go  :  14.00 

1-T19 

-1 

Bt 

1-T13  -1 

xlOO  ripple  in 

weighting  :+0. 00000000 

G 

time  so  far:  6.00 

to  page 

cost  to  go  :  5.00 

0016 

time  to  go  :  5.00 

1-T10 

-1 

B  1  . . 

1-T14  -1 

|  ******  FAULT 

****** 

1 

x  10  ripple  in 

1 

ISus  AG  Ref#: 

I 

11 

1 

1 

weighting  :+0. 00000000 

G 

i 

(cumulative  totals 

1 

1 

— 

I  tests: 

5 

1 

time  so  far:  7.00 

I  test  cost: 

8.00 

1 

cost  to  go  :  4.00 

I  test  time: 

8.00 

I 

time  to  go  :  4.00 

I  enclosures: 

1 

1 

1 

B  1 

1-T15  -1 

1  ******  FAULT 

****** 

1 

xl  counter  out 

1 

ISus  AG  Ref#: 

f 

10 

1 

I 

| 

weighting  :+0. 00000000 

G 

i 

(cumulative  totals 

1 

1 

— 

(  tests: 

6 

1 

time  so  far:  8.00 

I  test  cost: 

9.00 

1 

cost  to  go  :  3.00 

I  test  time: 

9.00 

1 

time  to  go  :  3.00 

I  enclosures: 

1 

1 

1 

B |  FAULT 
to  page  0015  I  9 


FAULT  ISOLATION  INDICATOR  REPORT 


DETAIL  ANALYSIS 


Diagnostic  Flow  Diagram 


from  page  |  1-T15 

0014  |  -1 

_ B  | _ 

******  FAULT  ****** 

Sus  AG  Ref#:  9 

cumulative  totals 
tests:  6 

test  cost:  9-00 

test  time:  9.00 

enclosures:  1 


from  page 
0014 
1-T13 
-1 


1-T10  -1 

xlOO  counter  out 


weighting  :+0. 00000000 


time  so  far: 
cost  to  go  : 
time  to  go  : 


7.00 

4.00 

3.00 


******  fault  ****** 

Sus  AG  Ref#:  12 

cumulative  totals 
tests:  5 

test  cost:  8.00 

test  time:  8.00 

enclosures:  1 


******  FAULT  ****** 

Sus  AG  Ref#:  13 

cumulative  totals 
tests:  5 

test  cost:  8.00 

test  time:  8.00 

enclosures:  1 


FAULT  ISOLATION  INDICATOR  REPORT 


DETAIL  ANALYSIS 


Diagnostic  Flow  Diagram 


from  page 
0014 
1-T16 
-1 


1-T19  -1 

VFAKE  inverse 


weighting  :+0. 00000000 


time  so  far: 
cost  to  go  : 
time  to  go  : 


6.00 

11.00 

10.00 


1-T18  -1 

count  9  HSYNC  pulse 


weighting  :+0. 00000000 


7.00 

10.00 

9.00 


time  so  far: 
cost  to  go  : 
time  to  go  : 


1-T17  -1 

count  262  pulse 


weighting  :+0. 00000000 


time  so  far: 
cost  to  go  : 
time  to  go  : 


9.00 

8.00 

7.00 


FAULT 


****** 


Sus  AG  Ref#:  14 

cumulative  totals 
tests:  6 

test  cost:  13.00 

test  time:  13.00 

enclosures:  1 


******  FAULT  ****** 

Sus  AG  Ref#:  16 

cumulative  totals 
tests:  5 

test  cost:  9.00 

test  time:  9.00 

enclosures:  1 


****** 


FAULT 


****** 


Sus  AG  Ref#:  15 

cumulative  totals 
tests:  6 

test  cost:  13.00 

test  time:  13.00 

enclosures:  1 


to  page 
0018 
1-T20 
-1 


FAULT  ISOLATION  INDICATOR  REPORT 


DETAIL  ANALYSIS 
Diagnostic  Flow  Diagram 


1-T20  -1 

IVFAKE  &  non-intrl 


[weighting  :+0. 00000000 


from  page 
0017 
1-T19 
-1 


I  time  so  far 
cost  to  go 
I  time  to  go 


7.00 

2.00 

3.00 


B  I 


******  FAULT  ****** 

Sus  AG  Ref#:  17 

cumulative  totals 
tests:  5 

test  cost:  8.00 

test  time:  8.00 

enclosures:  1 


******  FAULT  ****** 

Sus  AG  Ref#:  18 

cumulative  totals 
tests:  5 

test  cost:  8.00 

test  time:  8.00 

enclosures:  1 


G 


from  page 
0009 
1-T26 
-1 


1  1-T27  -1 

1 

1 

I HNEW  inverse  out 

1 

1 

1 

|  NO  FAULTS  ENCOUNTERED 

1 

1 

1  weighting  :+0. 00000000 

1 

1 

1 

G  | cumulative  totals 

1 

1 

- 1  tests:  2 

Itime  so  far: 

1.00 

1 

|  test  cost: 

2.00 

1  cost  to  go  : 

2.00 

1 

|  test  time: 

2.00 

Itime  to  go  : 

1 

3.00 

1 

|  enclosures:  1 

1 

B  | 

1  ******  fault  *  *  *  *  * * 

1 

1 

1 

1 

1  Sus  AG  Ref#:  19 

1 

1 

i 

1  cumulative  totals 

1 

1 

1  tests:  2 

1 

1  test  cost: 

2.00 

1 

1  test  time: 

2.00 

1 

1  enclosures:  1 

1 
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EXAMPLE  DATA  ENCODING  FORMAT 


STAT-PAWS  DATA  ENCODING  FORMAT 
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•H  X  (0 
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w  x  m 
a)  x  in 
a  x 
IX  o 
H  X  4-1 
TJ  X 

s  x  a 

n*  X  3 
V>  X 


</>  iH 

n.  Q) 

4J  73 

coo 

0)  S  H 


O  W  TJ 

H  o 

rH  S 

T3  W 
£‘H  P 
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X  X 
</>  X  X 
n.  X  X 
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C  X  X 
Q)  X  X 

e  x  x 
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U  X  X 
IX  X 
rH  X  X 
TJXX 
£  X  X 
n-  X  X 
V>  X  X 


o 

O  P  P 

c  c 

H  5)  (I 

■oil 
0  0  0 
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3X3 

x:  x  p 

O  X  (0 
IX  JS 
p  x  o 
a)  x 
w  x  in 

D  X  H 
IX 

P  X  0 
W  X  P 
<U  X 
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n>  X  3 
t/>  X  — ■ 


3  X  (0 
JC  X  P 
0X3 
IX  JC 
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O  X 
w  x  in 
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IX 
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<U  X  P 
P  X 

h  x  a 
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V>  X 


OETEX  Systems,  Inc.  reserves  the  right  to  change  this  specification  at  any  time  without  notice. 
Copyright  (c)  1990  OETEX  Systems,  Inc.  All  rights  reserved. 

Reprinted  with  permission 


STAT-PAWS  Interchange  Format  continued 


■0 

® 

3 

a 

•rl 

P 

a 

o 

o 

i 

n 

a 

o 

•rt 

•P 

•rl 

a 

•H 

« 

o 

p 

id 

a 

u 

o 

Pm 

® 


Pm 

P 

M 

O 

& 

M 

P 

P 

O 

a 


■o 

M 

id 

■o 

0 

id 

■p 

oo 


H 

I 

U 

w 

PJ 


s 


frl 


fM 

I 

u 


DETEX  Systems,  Inc.  reserves  the  right  to  change  this  specification  at  any  time  without  notice. 
Copyright  (c)  1990  OETEX  Systems,  Inc.  All  rights  reserved. 


STAT-PAWS  Interchange  Format  Continued 


« 

3 

a 

•rt 

P 

C 

o 

o 


n 

a 

o 

•H 

P 

■H 

c 


« 

Q 

P 

id 

fi 

p 

o 

fa 


■rl 

fa 

P 

P 

o 

& 

w 

p 

p 

o 

a 

s 


■d 

p 

id 

•o 

a 

id 

P 

to 


H 

I 

CJ 

w 

s 


l 

u 


OETEX  Systems,  Inc.  reserves  the  right  to  change  this  specification  at  any  time  without  notice. 
Copyright  (c)  1990  OETEX  Systems,  Inc.  All  rights  reserved. 


STAT-PAWS  Interchange  Format  Continued 
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$@Define  Test@$ 

T100-1 

$?Test  Category?$ 

D 

$?Test_Description?$ 

Test  Input  to  X 

$?Test  Type?$ 

P 

$?Test  Cost?$ 

30.50 
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$@Start  Mdl  Definition§$ 
S-1M-10 

$?Mdl_Description?$ 

Sample  Diagram 
$?Mdl_Comment?  $ 

This  example  Model  has  been 
designed  to  demonstrate  the 
Import/Export  File  Format. 
$?Test_User_Char_Name?$ 
Criticality 

$?Item  User_Char_Name?$ 
Availability 
$@Define  Item@$ 

11 

$?Item  Description?$ 

Block  A 
$?Item  Cost?$ 

12.75 

$?Item_Time?$ 

20.00 

$?Item  Failure_Rate?$ 
0.0001^620 
$?Item_User_Char?$ 

100.53 

$@Define  Item  Aspect@$ 

1 

$?  I  Asp  Description?$ 

Block  A  -  Pin  1 
$?Detectability?$ 

D 

$?Apportionment?$ 

1 

$@Define  Item@$ 

12 

?Item_Description?$ 

Block  B 
$?Item_Cost?$ 

102.50 

$?Item_Time?$ 

110.00 

$?Item_Failure_Rate?$ 

0.00001250 

$?Item_User_Char?$  52.50 
$@Def ine_I tem_Aspect@  $ 

1 


FIGURE  C-2  (Sample  Import/Export  File) 


C-8 


DETEX  Systems,  Inc.  reserves  the  right  to  change  this  specification  at  any  t;me  without  notice 
Copyright  (c)  1990  OETEX  Systems,  Inc.  Alt  rights  reserved. 


I 

I 

I 

I 


$?_I  Asp_Description?$ 
Block  B  -  Pin  1 
$?Detectability?$ 

D 

$?Apportionment?$ 

1 

$@Define  Item@$ 

13 

$?Item  Description? $ 
Block  C 
$?Item  Cost?$ 

180.00 

$?Item  Time?$ 

150.00 

$?Item  Failure  Rate?$ 

0 . 0000(5528 
$?Item  User  Char?$ 

2.00 

$@Define  Item_Aspect@$ 
1 

$?_I  Asp_Description?$ 
Block  C  -  Pin  1 
$?Detectability?$ 

D 

$?Apportionment?$ 

1 

$@Define  Item@$ 

14 

$?Item  Description?$ 
Block  D 
$?Itexn  Cost?$ 

5.00  ” 

$?Item  Time?$ 

10.00 

$?Item  Failure  Rate?$ 
0. 00012500 
$?Item  User_Char?$ 
98.60 

$@Define  Item_Aspect@$ 
1 

$?_I  Asp_Descri'ption?$ 
Block  D  -  Pin  1 
$?Detectability?$ 

D 

$?Apportionment?$ 

1 


FIGURE  C-2  (Sample  Import/Export  File  -  continued) 
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/A( 


I 

$@Define  Item  Aspect@$ 
2 

$?_I  Asp_Description?$ 
Block  D  -  Pin  2 
$?Detectability?$ 

D 

$?Apportionment?$ 

1 

$@Define  Item@$ 

15 

$?Item  Description?$ 
Block  E 
$?Item_Cost?$ 

400.00 

$?Item_Time?$ 

20.00 

$?Item_Failure_Rate?$ 
0.00009520 
$?Item_User  Char?$ 
100.53 

$@Def ine_Item_Aspect@$ 
1 

$?_I  Asp_Description?$ 
Block  E  -  Pin  1 
$  ?  Detectabi 1 i ty ?  $ 

D 

$  ? Appor t i onmen t ?  $ 

1 

$@Define  Item@$ 

16 

$?Item  Description?? 
Block  F 
$?Item_Cost?$ 

12.75 

$?Item_Time?$ 

20.00 

$?Item  Failure_Rate?$ 

0.0001TJ620 

$? I tem_User_Char ?  $ 

100.53 

$@Def ine_Item_Aspect@  $ 
1 

$?_I  Asp_Description?$ 
Bloclc  F  -  Pin  1 
$?Detectability?$ 

D 

$?Apportionment?$ 

1 


FIGURE  c-2  (Sample  Import /Export  File  -  continued) 

C-10 
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$@Define  Item@$ 

17 

$?Item  Description?$ 
Block  5 
$?Item  Cost?$ 

89.99  ~ 

$?Itsm  Time?$ 

35.50  “ 

$?Item  Failure  Rate?$ 
0.00007800 
$?Item_User  Char?$ 
100.53 

$@Define  Item  Aspect@$ 
1 

$?_I  Asp_Description?$ 
Bloclc  G  -  Pin  1 
$?Detectability?$ 

D 

$?Apportionment?$ 

1 

$@Define  Item@$ 

18 

$?Item  Description? $ 
Block  H 
$?Item  Cost?$ 

20.50  “ 

$?Item  Time?$ 

19.44  ~ 

$?Item  Failure  Rate?$ 
0.0002^667 
$?Item  User  Char?$ 
10.00  ~ 

$@Define  Item_Aspect@$ 
1 

$?_I  Asp_Description?$ 
Bloclc  H  -  Pin  1 
$?Detectability?$ 

D 

$  ? Appor t ionment ?  $ 

1 

$@Def ine_Test@$ 

Tl-1 

$?Test_Cat.egory?$ 

D 

$?Test  Description?$ 
Input  to  Block  A 


FIGURE  C-2  (Sample  Import/Export  File  -  continued) 
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I 

$?Test  Type?$ 

P 

$?Test  Cost?$ 

35.00 

$?Test  Time?$ 

7.00 

$?Test  User  Char?$ 
500.00 

$?Test_Enclosure?$ 

1 

$?Test_Level?$ 

1 

$@Dependencies@$ 
$@Define  Test@$ 

T2-1 

$?Test  Category?$ 

D 

$?Test  Description?$ 
Input  to  Block  D 
$?Test_Type?$ 

P 

$?Test  Cost?$ 

107.00 

$?Test_Time?$ 

23.50 

$?Test  User_Char?$ 
150.75 

$?Test_Enclosure?$ 

1 

$  ?  Tes t_Le ve 1 ?  $ 

1 

$@Dependencies@$ 
$@Define  Test@$ 

T3-1 

$  ?Test_Category ?  $ 

D 

$?Test  Description?$ 
Input  to  Block  G 
$?Test  Type?$ 

P 

$?Test_Cost?$ 

103.00 

$?Test  Time?$ 

1005.0ft 

$?Test  User  Char?$ 
10.00  ~ 


FIGURE  C-2  (Sample  Import/Export  File  -  continued) 


C-12 

OETEX  Systems,  Inc.  reserves  the  right  to  change  this  specification  at  any  time  without  notice. 
Copyright  (c)  1990  DETEX  Systems,  !nc.  All  rights  reserved. 


V/ 


$?Test  Enclosure?$ 

1 

$?Test  Level?$ 

1 

$@Dependencies@$ 
$@Define  Test@$ 

T4-1 

$?Test  Category? $ 

D 

$?Test_Description?$ 
Test  @  11-1 
$?Test  Type?$ 

P 

$?Test  Cost?$ 

195.00 

$?Test  Time?$ 

32.50 

$?Test  User  Char?$ 
500.00 

$?Test  Enclosure?$ 

1 

$?Test_Level?$ 

1 

$@Dependencies@$ 

11-1 

Tl-1 

$@Define  Test@$ 

T5-1 

$  ?Test_Cat egory ?  $ 

D 

$?Test_Description?$ 
Output  @  13-1 
$?Test_Type?$ 

P 

$?Test_Cost?$ 

240.00 

$?Test_Time?$ 

5.00 

$?Test_User_Char?$ 

100.00 

$?Test_Enclosure?$ 

1 

$?Test_Level?$ 

1 

$@Dependencies@$ 

13-1 

12-1 

T4-1 


FIGURE  C-2  (Sample  Import/Export  File  -  continued) 
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$@Def ine_Test@$ 

T6-1 

$?Test  Category?$ 

D 

$?Test_Descr ipt ion?  $ 
Output  @  14-1 
$?Test  Type?$ 

P 

$?Test  Cost?$ 

35.00 

$?Test  Time?$ 

7.00 

$?Test_User_Char?$ 

500.00 

$?Test_Enclosure?$ 

1 

$?Test_Level?$ 

1 

$@Dependencies@$ 

14-1 

T4-1 

Tll-1 

$@Define  Test@$ 

T7-1 

$?Test  Category? $ 

D 

$?Test_Description?$ 
Output  @  16-1 
$?Test_Type?$ 

P 

$?Test_Cost?$ 

45.00 

$?Test_Time?$ 

5.00 

$?Test_User_Char ?  $ 
40.00 

$?Test  Enclosure? $ 

1 

$?Test  Level?$ 

1 

$@Dependenc ies@  $ 

16-1 

T10-1 


FIGURE  C-2  (Sample  Import/Export  File  -  continued) 


C-14 

DETEX  Systems,  Inc.  reserves  the  right  to  change  this  specification  at  any  time  without  notice. 
Copyright  (c)  1990  DETEX  Systems,  Inc.  All  rights  reserved. 

/  4z 


$@Define  Test§$ 

T8-1 

$?Test  Category? $ 

D 

$?Test  Description?$ 
Output  @  18-1 
$?Test  Type?$ 

P 

$?Test  Cost?$ 

100.00 

$?Test_Time?$ 

100.00 

$?Test_User_Char?$ 

5.00 

$?Test_Enclosure?$ 

1 

$?Test_Level?$ 

1 

$@Dependencies@$ 

18-1 

T9-1 

$@Define  Test@$ 

T9-1 

$?Test  Category? $ 

D 

$?Test_Description?$ 
Test  @  17-1 
$?Test_Type?$ 

P 

$?Test_Cost?$ 

35.00 

$?Test_Tixne?$ 

7.00 

$?Test_User_Char?$ 

500.00 

$?Test_Enclosure?$ 

1 

$?Test_Level?$ 

1 

$@Dependencies@$ 

17-1 

T3-1 


FIGURE  c-2  (Sample  import /Export. File  -  continued) 
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$@Define  Test@$ 

T10-1 

$?Test  Category? $ 

D 

$?Test_Description?$ 
Test  @  14-2 
$?Test  Type?$ 

P 

$?Test  Cost?$ 

125.75 

$?Test  Time?$ 

130.00 

$?Test_User_Char?$ 

25.00 

$?Tcst  Enclosure?$ 

1 

$?Test  Level?$ 

1 

$@Dependencies@$ 

14- 2 
T2-1 
Tll-1 

$@Def ine_Test§$ 

Tll-1 

$?Test  Category?$ 

D 

$?Test  Description?$ 
Test  15-1 
$?Test_Type?$ 

P 

$?Test_Cost?$ 

35.00 

$?Test_Time?$ 

21.00 

$?Test_User_Char?$ 

65.00 

$?Test_Enclosure?$ 

1 

$?Test_Level?$ 

1 

$@Dependencies@$ 

15- 1 
T3-1 

$@End  Mdl  Definition@$ 


FIGURE  C-2  (Sample  Import/Export  File  -  continued) 
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APPENDIX  4 


Dependency  Model  for  the  High 
Voltage  Power  Supply  from  the  AV- 
8B  Heads-up  Display,  HV-A2. 


File  Name:  HVA2 


File 

Description: 

HIGH 

VOLTAGE 

POWER  SUPPLY  A2 

MODEL 

File 

Date: 

15SEPT89 

Weight  Printed  is 

Time 

of  making  test 

Test 

1 

Label 

= 

TA2P1-1 

Weight  = 

3.00 

Test 

2 

Label 

= 

TA2P1-11 

Weight  = 

3.00 

Test 

3 

Label 

= 

TA2P1-12 

Weight  = 

3.00 

Test 

4 

Label 

= 

TA2P1-13 

Weight  = 

3.00 

Test 

5 

Label 

= 

TA2P1-14 

Weight  = 

3.00 

Test 

6 

Label 

SB 

TA2P1-17 

Weight  = 

3.00 

Test 

7 

Label 

= 

TA2P1-19 

Weight  = 

3.00 

Test 

8 

Label 

= 

TA2P1-2 

Weight  = 

3.00 

Test 

9 

Label 

= 

TA2P1-20 

Weight  = 

3.00 

Test 

10 

Label 

= 

TA2P1-23 

Weight  = 

3.00 

Test 

11 

Label 

= 

TA2P1-24 

Weight  = 

3.00 

Test 

12 

Label 

= 

TA2P1-25 

Weight  = 

3.00 

Test 

13 

Label 

= 

TA2P1-2  6 

Weight  = 

3.00 

Test 

14 

Label 

= 

TA2P1-27 

Weight  = 

3 . 00 

Test 

15 

Label 

= 

TA2P1-29 

Weight  = 

3.00 

Test 

16 

Label 

= 

TA2P1-3 

Weight  = 

3.00 

Test 

17 

Label 

= 

TA2P1-30 

Weight  = 

3.00 

Test 

18 

Label 

= 

TA2P1-31 

Weight  = 

3.00 

Test 

19 

Label 

= 

TA2P1-32 

Weight  = 

3.00 

Test 

20 

Label 

= 

TA2P1-33 

Weight  = 

3 . 00 

Test 

21 

Label 

= 

TA2P1-34 

Weight  = 

3.00 

Test 

22 

Label 

= 

TA2P1-36 

Weight  = 

3 . 00 

Test 

23 

Label 

= 

TA2P1-37 

Weight  = 

3.00 

Test 

24 

Label 

= 

TA2P1-5 

Weight  = 
Weight  = 

3.00 

Test 

25 

Label 

= 

TA2P1-6 

3.00 

Test 

26 

Label 

= 

TA2P1-7 

Weight  * 

3.00 

Test 

27 

Label 

= 

TA2P1-8 

Weight  = 

3.00 

Test 

28 

Label 

= 

TA2P1-9 

Weight  = 

3.00 

Test 

29 

Label 

= 

TP1-A2 

Weight  = 

3.00 

Test 

30 

Label 

= 

TP2-A2 

Weight  = 

3.00 

Test 

31 

Label 

•EC 

TP3-A2 

Weight  = 

3 . 00 

Test 

32 

Label 

= 

TP4-A2 

Weight  = 

3 . 00 

Test 

33 

Label 

= 

TXA2P1-11 

Weight  = 

3 . 00 

Test 

34 

Label 

= 

TXA2P1-13 

Weight  = 

3 . 00 

Test 

35 

Label 

= 

TXA2P1-23 

Weight  = 

3.00 

Test 

36 

Label 

= 

TXA2P1-14 

Weight  = 

3.00 

Test 

37 

Label 

= 

TXA2P1-7 

Weight  = 

3.00 

Test 

38 

Label 

= 

TYA2P1-20 

Weight  = 

3.00 

Test 

39 

Label 

= 

TXA2P1-8 

Weight  - 

3.00 

Test 

40 

Label 

= 

TXP3-A2 

Weight  = 

3.00 

Test 

41 

Label 

= 

TXP4-A2 

Weight  = 

3.00 

Test 

42 

Label 

as 

TYA2P1-17 

Weight  = 

3 . 00 

Test 

43 

Label 

= 

TR16 

Weight  = 

3.00 

Test 

45 

Label 

= 

TR17 

Weight  = 

3.00 

Test 

47 

Label 

= 

TR33 

Weight  = 

3.00 

Test 

48 

Label 

= 

TR35 

Weight  = 

3.00 

Test 

49 

Label 

= 

TPA-A2 

Weight  = 
Weight  = 

3.00 

Test 

50 

Label 

= 

TXA2P1-25 

3.00 

Test 

51 

Label 

= 

TXA2P1-32 

Weight  = 

3.00 

Test 

52 

Label 

= 

T+30STTO 

Weight  = 

3.00 

Test 

53 

Label 

= 

T+15STTC 

Weight  = 

3.00 

Test 

5; 

Label 

as 

T-15STTO 

Weight  = 

3.00 

Test 

55 

Label 

= 

TR14 

Weight  = 

3.00 

Test 

56 

Label 

= 

TYA2P1-8 

Weight  = 

3.00 

End  of  weight  display.  Weight^  Time  of  making  test 


File  Name:  HVA2 
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A2R18 

(CP41) 

A2R19 

(CP43) 

A2R20 

(CP44) 

A2R21 

(CP46) 

A2R23 

( CP4  7 ) 

A2R24 

(  CP4  9 ) 

A2R26 

(CP50) 

A2R27 

(CP51) 

A2R28 

n(3 


(CP52 ) 

A2R29 

(CP54 ) 

A2R30 

(CP57 ) 

A2R33 

(CP58) 

A2R34 

(CP66) 

A2U1A 

(CP68 ) 

GNDA 

(CP70) 

GNDD 

Test 

31  Label  = 

(TE31)  TP3- 

A2 

Dependencies: 

(TE9) 

TA2P1-20 

( CP4  8 ) 

A2R25 

(CP49) 

A2R26 

Test 

32  Label  = 

(TE32)  TP4- 

A2 

Dependencies : 

(TE4) 

TA2P1-13 

(TE5) 

TA2P1-14 

(TE9) 

TA2P1-20 

(TE10) 

TA2P1-23 

(TE26) 

TA2P1-7 

(TE30) 

TP2-A2 

(CP9) 

A2C8 

(CP12) 

A2CR10 

(CP22) 

A2CR9 

(CP28) 

A2Q6 

(CP29) 

A2Q7 

(CP30) 

A2Q8 

(CP40) 

A2R18 

(CP41) 

A2R19 

(CP43) 

A2R20 

(CP44) 

A2R21 

(CP46) 

A2R23 

(CP47 ) 

A2R24 

(CP49) 

A2R26 

(CP50) 

A2R27 

(CP51) 

A2R28 

(CP52) 

A2R29 

(CP54) 

A2R30 

(CP55) 

A2R31 

(CP66) 

A2U1A 

(CP68) 

GNDA 

Test 

33  Label  = 

(TE33 )  TXA2P1-11 

Dependencies : 

Test 

34  Label  = 

(TE34 )  TXA2P1-13 

Dependencies : 

Test 

35  Label  = 

(TE35)  TXA2P1— 23 

Dependencies: 

Test 

36  Label  = 

(TE36)  TXA2P1-14 

Dependencies: 

(TE33) 

TXA2P1-11 

(TE35) 

TXA2P1-23 

(CP70) 

GNDD 

Test 

37  Label  = 

(TE37 )  TXA2P1-7 

Dependencies : 

Test 

38  Label  = 

(TE38)  TYA2P1-20 

Dependencies : 

Test 

39  Label  = 

(TE39)  TXA2P1-8 

Dependencies : 

(TE33) 

TXA2P1-11 

(TE34) 

TXA2P1-13 

(TE35) 

TXA2P1-23 

(TE36) 

TXA2P1-14 

(TE37) 

TXA2P1-7 

(CP9) 

A2C8 

(CP40) 

A2R18 

(CP41) 

A2R19 

(CP43 ) 

A2R20 

(CP44 ) 

A2R21 

(CP45) 

A2R22 

(CP66) 

A2U1A 

(CP68 ) 

GNDA 

(CP70) 

GNDD 

(CP101) 

A2C8S 

(CP102) 

A2U1-2 

Test 

40  Label  = 

(TE40)  TXP3 

-A2 

Dependencies: 

(TE38) 

TYA2P1-20 

(TE49) 

TPA-A2 

(CP48 ) 

A2R25 

(CP49) 

A2R26 

Test 

41  Label  = 

(TE41)  TXP4 

-A2 

Dependencies : 

(TE35) 

TXA2P1-23 

(TE38) 

TYA2P1-20 

(TE49) 

TPA-A2 

(CP3) 

A2C11 

(CP12) 

A2CR10 

(CP22) 

A2CR9 

(CP29) 

A2Q7 

(CP30) 

A2Q8 

(CP49) 

A2R26 

(CP50) 

A2R27 

(CP51) 

A2R28 

(CP52 ) 

A2R29 

(CP54 ) 

A2R30 

(CP55) 

A2R31 

(CP57 ) 

A2R33 

(C 

P58) 

A2R34 

(CP68) 

GNDA 

(CP70) 

GNDD 

Test 

42  Label  = 

(TE42)  TYA2P1-I7 

Dependencies : 

(TE35) 

TXA2P1-23 

(TE38) 

TYA2P1-20 

(TE49 ) 

TPA-A2 

(CP3) 

A2C11 

(CP12) 

A2CR10 

(CP13) 

A2CR11 

(CP14) 

A2CR12 

(CP22) 

A2CR9 

(CP29) 

A2Q7 

(CP30) 

A2Q8 

(CP49) 

A2R26 

(CP50) 

A2R27 

(CP51) 

A2R28 

(CP52) 

A2R29 

(CP54) 

A2R30 

(CP56) 

A2R32 

(CP57) 

A2R33 

(CP58) 

A2R34 

(CP68) 

GNDA 

(CP70) 

GNDD 

Test 

43  Label  = 

(TE43 )  TR16 

Dependencies: 

( CP96) 

A2R16 

(CP102) 

A2U1-2 

Test 

45  Label  = 

(TE45)  TR17 

Dependencies: 

(CP82) 

A2C10 

(CP94 ) 

A2R17 

(CP98 ) 

A2U1-11 

(CP101) 

A2C8S 

(CP102 ) 

A2U1-2 

(CP105) 

A2CR12S 

Test 

47  Label  = 

(TE47 )  TR33 

Dependencies: 

(CP3) 

A2C11 

(CP57) 

A2R3  3 

(CP58) 

A2R34 

Test 

48  Label  = 

(TE48 )  TR35 

Dependencies: 

(CP92 ) 

A2R35 

(CP93 ) 

A2C12 

Test 

49  Label  = 

(TE49 )  TPA-A2 

Dependencies : 

(TE33 ) 

TXA2P1-11 

(TE34 ) 

TXA2P1-13 

(TE35) 

TXA2P1-23 

(TE36) 

TXA2P1-14 

(TE37 ) 

TXA2P1-7 

(TE38 ) 

TYA2P1-2  0 

(CP3) 

A2C11 

(CP9) 

A2C8 

(CP12) 

A2CR10 

(CP22 ) 

A2CR9 

(CP28) 

A2Q6 

(CP29) 

A2Q7 

(CP40) 

A2R18 

(CP4 1) 

A2R19 

(CP43 ) 

A2R20 

(CP44 ) 

A2R21 

(CP46) 

A2R23 

(CP47 ) 

A2R24 

(CP49) 

A2R26 

(CP66) 

A2U1A 

(CP68 ) 

GNDA 

(CP70) 

GNDD 

(CP101) 

A2C8S 

(CP102 ) 

A2U1-2 

(CP105) 

A2CR12S 

Test 

50  Label  = 

(TE50)  TXA2P1-2  5 

Dependencies : 

(TE10) 

TA2P1-23 

(CP68) 

GNDA 

(CP71) 

A2C7S 

(CP72 ) 

A2C6S 

(CP73 ) 

A2CR8S 

Test 

51  Label  = 

(TE51)  TXA2P1-32 

Dependencies: 

(TE10) 

TA2P1-23 

(CP8) 

A2C7 

(CP21) 

A2CR8 

(CP68 ) 

GNDA 

(CP'/ 1) 

A2C7S 

(CP72 ) 

A2C6S 

(CP73) 

A2CR8S 

Test 

52  Label  = 

(TE52 )  T+30STTO 

Dependencies: 

(CP6) 

A2C3 

Test 

53  Label  = 

(TE53 )  T+15STTO 

Dependencies : 
(CP81)  A2C9 


(CP100)  A2U1-4 


Test  54  Label  «  (TE54)  T-15STTO 

Dependencies : 

(CP82)  A2C10  (CP98)  A2U1-11 

Test  55  Label  =  (TE55)  TR14 

Dependencies : 

(CP86)  A2U1-3  (CP95)  A2R14 

Test  56  Label  =  (TE56)  TYA2P1-8 

Dependencies: 

(CP84 )  A2R15  (CP86)  A2U1-3 

End  of  dependency  display 


/ 


File  Name: 

File  Description: 
File  Date: 


HVA2 

HIGH  VOLTAGE  POWER  SUPPLY  A2  MODEL 
15SEPT89 


End  of  associated  failure  group  display 


File  Name:  HVA2 

File  Description:  HIGH  VOLTAGE  POWER  SUPPLY  A2  MODEL 
File  Date:  15SEPT89 


Weight  Printed 
Test  1 

is  Test  Costs 
Label 

_ 

TA2P1-1 

Weight  = 

0.00 

Test 

2 

Label 

= 

TA2P1-11 

Weight  = 

0.00 

Test 

3 

Label 

= 

TA2P1-12 

Weight  = 

0.00 

Test 

4 

Label 

= 

TA2P1-13 

Weight  = 

0.00 

Test 

5 

Label 

= 

TA2P1-14 

Weight  = 

0.00 

Test 

6 

Label 

= 

TA2P1-17 

Weight  = 

0.00 

Test 

7 

Label 

= 

TA2P1-19 

Weight  = 

0.00 

Test 

8 

Label 

= 

TA2P1-2 

Weight  = 

0.00 

Test 

9 

Label 

= 

TA2P1-20 

Weight  = 

0.00 

Test 

10 

Label 

= 

TA2P1-23 

Weight  = 

0.00 

Test 

11 

Label 

= 

TA2P1-24 

Weight  = 

0.00 

Tesc 

12 

Label 

SB 

TA2P1-25 

Weight  = 

0.00 

Test 

13 

Label 

= 

TA2P1-26 

Weight  = 

0.00 

Test 

14 

Label 

= 

TA2P1-27 

Weight  = 

0.00 

Test 

15 

Label 

= 

TA2P1-29 

Weight  = 

0.00 

Test 

16 

Label 

= 

TA2P1-3 

Weight  = 

0.00 

Test 

17 

Label 

= 

TA2P1-30 

Weight  = 

0.00 

Test 

18 

Label 

= 

TA2P1-31 

Weight  = 

0.00 

Test 

19 

Label 

= 

TA2P1-32 

Weight  = 

0.00 

Test 

20 

Label 

= 

TA2P1-33 

Weight  = 

0.00 

Test 

21 

Label 

= 

TA2P1-34 

Weight  = 

0.00 

Test 

22 

Label 

= 

TA2P1-36 

Weight  = 

0.00 

Test 

23 

Label 

= 

TA2P1-37 

Weight  = 

0.00 

Test 

24 

Label 

= 

TA2P1-5 

Weight  = 

0.00 

Test 

25 

Label 

= 

TA2P1-6 

Weight  = 

0.00 

Test 

26 

Label 

= 

TA2P1-7 

Weight  = 

0.00 

Test 

27 

Label 

= 

TA2P1-8 

Weight  = 

0.00 

Test 

28 

Label 

= 

TA2P1-9 

Weight  = 

0.00 

Test 

29 

Label 

= 

TP1-A2 

Weight  = 

0.00 

Test 

30 

Label 

= 

TP2-A2 

Weight  = 

0.00 

Test 

31 

Label 

= 

TP3-A2 

Weight  = 

0.00 

Test 

32 

Label 

SB 

TP4-A2 

Weight  = 

0.00 

Test 

33 

Label 

= 

TXA2P1-11 

Weight  = 

0.00 

Test 

34 

Label 

= 

TXA2P1-13 

Weight  = 

0.00 

Test 

35 

Label 

= 

TXA2P1-23 

Weight  = 

0.00 

Test 

36 

Label 

= 

TXA2P1-14 

Weight  = 

0.00 

Test 

37 

Label 

=s 

TXA2P1-7 

Weight  = 

0.00 

Test 

38 

Label 

= 

TYA2P1-20 

Weight  = 

0.00 

Test 

39 

Label 

= 

TXA2P1-8 

Weight  = 

0.00 

Test 

40 

Label 

= 

TXP3-A2 

Weight  = 

0.00 

Test 

41 

Label 

SB 

TXP4-A2 

Weight  = 

0.00 

Test 

42 

Label 

S= 

TYA2P1-17 

Weight  = 

0.00 

Test 

43 

Label 

= 

TR16 

Weight  = 

0.00 

Test 

45 

Label 

= 

TR17 

Weight  = 

0.00 

Test 

47 

Label 

= 

TR3  3 

Weight  = 

0.00 

Test 

48 

Label 

s= 

TR35 

Weight  = 

0.00 

Test 

49 

Label 

= 

TPA-A2 

Weight  = 

0.00 

Test 

50 

Label 

= 

TXA2P1-25 

Weight  = 

0.00 

Test 

51 

Label 

= 

TXA2P1-32 

Weight  = 

0.00 

Test 

52 

Label 

= 

T+30STTO 

Weight  = 

0.00 

Test 

53 

Label 

s 

T+15STTO 

Weight  = 

0.00 

Test 

54 

Label 

= 

T-15STTO 

Weight  = 

0.00 

Test 

55 

Label 

= 

TR14 

Weight  = 

0.00 

Test 

56 

Label 

=s 

TYA2P1-8 

Weight  = 

0.00 

End  of  weight  display. 
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File  Name:  HVA2 

File  Description:  HIGH  VOLTAGE  POWER  SUPPLY  A2  MODEL 
File  Date:  15SEPT89 

Associated  component  group  TEST  RESISTORS 


(CP31) 

A2R1 

(CP45) 

A2R22 

(CP48) 

A2R25 

(CP55) 

A2R31 

(CP62) 

A2R6 

(CP63) 

A2R7 

(CP65) 

A2R9 

Associated  component 

group  FOCUS 

FB 

(CP7) 

A2C6 

(CP20) 

A2CR7 

Associated  component 

group  +15KV 

OSC  0UT2 

(CP24) 

A2Q2 

(CP17) 

A2CR4 

Associated  component 

group  DYN  FOCUS  OUT 

(CP56) 

A2R32 

(CP13) 

A2CR11 

(CP14 ) 

A2CR12 

Associated  component 

group  DYN  FOCUS 

( CP2  8 ) 

A2Q6 

(CP29 ) 

A2Q7 

(CP30) 

A2Q8 

( CP4  0 ) 

A2R18 

(CP41) 

A2R19 

(CP43 ) 

A2R20 

(CP44) 

A2R21 

(CP46) 

A2R23 

(CP47) 

A2R24 

(CP50) 

A2R27 

(CP51) 

A2R28 

(CP52 ) 

A2R29 

(CP54) 

A2R30 

(CP57 ) 

A2R33 

(CP58 ) 

A2R34 

(CP66) 

A2U1A 

(CP3 ) 

A2C11 

(CP22 ) 

A2CR9 

(CP9) 

A2C8 

(CP12 ) 

A2CR10 

Associated  component 

group  FOCUS 

OSC  IN 

(CP64) 

A2R8 

(CP67 ) 

A2VR1 

(CP19 ) 

A2CR6 

Associated  component 

group  FOCUS 

OSC  BIAS 

(CP32) 

A2R10 

(CP33) 

A2R11 

(CP34 ) 

A2R12 

(CP35) 

A2R13 

Associated  component 

group  +15KV 

OSC  0UT1 

(CP23 ) 

A2Q1 

(CPU) 

A2CR1 

Associated  component 

group  +15KV 

OSC  BIAS 

(CP42) 

A2R2 

(CP53 ) 

A2R3 

(CP60) 

A2R4 

(CP61) 

A2R5 

(CPI) 

A2C1 

(CP5) 

A2C2 

(CP15) 

A2CR2 

(CP16) 

A2CR3 

Associated  component 

group  GROUNDS 

(CP68) 

GNDA 

(CP69) 

GNDC 

(CP70) 

GNDD 

End  of  associated  component  group  display 


